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Abstract 



The first linear-time planarity testing algorithm was developed in 1974 by Hopcroft and Tarjan 
(H&T) [32] using a method to split a biconnected graph up into edge disjoint paths and then 
sequentially embed them to test for planarity (a path addition method). Shortly afterwards 
Booth and Leuker [5] developed an alternative vertex addition linear-time planarity test, based 
on the earlier work of Lempel, Evan and Cederbaum [47], using a new PQ-Tree data structure. 
Since then there have been many developments in PQ-Tree vertex addition (and related PC-Tree 
edge addition) methods including authors such as: Chiba et al. [14]; Shih & Hsu [35, 69]; Boyer 
and Myrvold [10, 11]; and Haeupler and Tarjan [29]. 

In comparison, path addition has changed very little from the original algorithm. In 1984, 
Williamson [84] showed how H&T's algorithm can be extended to find Kuratowski sub-graphs 
in the event of a non-planar graph; and, in 1993, Mehlhorn, Mutzel and Naher [53] produced 
an implementation (in C) of H&T's algorithm and extended it to create a planar embedding 
of a graph. This has remained the state-of-the-art in path addition algorithms for over a 
decade. Recently 1 , de Fraysseix formulated an algorithm [15, 17], based on Tremaux Trees and 
a characterisation of planarity by W. Wu [87]; this may prove to be a highly optimised version 
of H&T's algorithm but is difficult to definitively prove as only an outline of its planarity testing 
phase is provided. These authors represent the majority of the work on path addition methods of 
planarity testing and embedding; indicating that it receives little attention compared to vertex 
or edge addition methods. 

This thesis attempts to reinvigorate the field of path addition and demonstrates: 

• How Tremaux Trees, which allow undirected connected graphs to be represented as a 
simple partial order relationship, are fundamentally related to H&T's planarity testing 
algorithm and includes some related invariant properties of these trees; 

• That the restriction on H&T's planarity testing algorithm to test undirected biconnected 
graphs can be relaxed to undirected connected graphs; 

• How to generate all possible embeddings of a biconnected component and how to extend 
this to generate all possible embeddings of separable graphs; and 

• Empirical Testing of various graph types and sizes to validate these results. 



At approximately the same time as the first eddition of this work 
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Chapter 1 



Introduction 



Graph Theory is a branch of mathematics and computer science that studies graphs. Graphs 
can be considered: in the abstract, as mathematical structures representing relationships (edges) 
between pairs of objects (vertices); or topologically, as an embedding consisting of curves (edges) 
connecting points (vertices) on a surface. Planar Graphs are a sub-set of graphs which have an 
embedding in the M 2 plane (or any other genus surface) such that: each vertex is at a distinct 
point on that plane; each edge is a simple curve; and no edges intersect except at their common 
vertices. Planar Graphs are useful in a wide variety of fields including: 

• Electronic circuit board design, where circuits printed onto a single layer must be planar; 

• Representation of transportation networks; 

• Determining isomorphism of chemical compounds (becomes easier if the graph represen- 
tation is planar); 

• Telecommunications networks using a spanning tree representation; and 

• Graphical representations of data - edge crossings have been identified as a major cause 
of confusion when comprehending the relationships within a graph [61-63, 80]; therefore, 
determining if a graph is planar and, hence, can be embedded without edge crossing can 
be used to eliminate one cause of miscomprehension and improve the usability of the graph 
visualisation. 



1.1 Motivation 

One of the remaining problems in the field of planar graphs is the creation of an algorithm to 
identify if a graph has more than one planar embedding and to generate those embeddings. 

Since 1930, when Kuratowski [44] published the first characterisation of planar graphs, there 
has been much research in the field of planar graphs. In 1974, Hopcroft and Tarjan (H&T) [32] 
published the first linear-time planarity testing algorith and then, in 1976, Booth and Lueker 
(B&L) [5] produced a second such algorithm. In 1985, Chiba et al. [14] extended B&L's algorithm 
to generate an embedding and the same was done for H&T's algorithm in 1993 by Mehlhorn, 
Mutzel, and Naher; however, both these extended algorithms only generate a single embedding 
for a graph. 
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The problem is to efficiently identify if an abstract graph can be displayed in a planar fashion 
and once this has been achieved to identify different possible planar representations of the same 
graph. There has been much research in this field and, particularly over the past 34 years 
since the first linear time algorithm by Hopcroft and Tarjan [32], there has been much work on 
simplifying and improving the efficiency of the algorithms. However, there are no algorithms 
published 1 that can identify all planar representations of a graph in linear time. 

The motivation for this thesis is to: 

• Give an overview of the developments in planar graph embedding, highlighting the lack of 
existing algorithms to generate multiple embeddings of a graph; and 

• Show that the algorithm presented is a new and novel method for generating all possible 
planar embeddings of a graph. 



1 Haeupler and Tarjan state a possible methodology of identifying all planar representations of a graph in their 
extended abstract (26th March 2008) [29] using a vertex addition method but have not provided details of the 
algorithm. 
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1.2 



Thesis Aims 



1. To give an explanation of Hopcroft and Tarjan's planarity test in terms of chains of related 
vertices and edges within a Tremaux Tree (Chapters 3-4); 

2. To show that Hopcroft and Tarjan's restriction on their planarity test of only processing 
biconnected graphs can be relaxed to consider connected graphs, in 0(£) time complexity 
(Chapter 4); 

3. To demonstrate the conditions where a graph allows for permutations of embeddings 
(Chapter 4); 

4. To produce an algorithm that identifies these permutations and can iterate through all 
possible permutations of a biconnected graph in 0(7) time, where T is the total number 
of permutations of embeddings of the graph (Chapter 5); 

5. To show how to generate an embedding (cyclic edge order) from this result in linear time 
(Chapter 4); 

6. To demonstrate how this can be extended (without specifying a time bound) to include 
separable graphs; and 

7. To empirically test the algorithm to demonstrate its linearity when testing for planarity 
(Chapter 7). 



This thesis will be split into four main sections: 

• Firstly, an overview to history of planar graph drawing (Chapter 2) and a commentary 
on the current state-of-the-art algorithms will be presented. The aim of this section is to 
identify the limits of current planarity testing algorithms and will show that the algorithm 
presented in the later sections provides a new and novel technique when compared to the 
current state-of-the-art. 

• The second section presents the concept of a Tremaux Tree (Chapter 3), a tree structure 
which defines a partial order on the graph, and shows how this tree can be partitioned 
into edge disjoint segments (chains of elements related within the Tremaux Tree) which 
can be used to test for planarity (Chapter 4) ; additionally, the partial order is investigated 
to show how it can be used to identify multiple embeddings. 

• The third section relates the previously defined concepts to an algorithm (Chapter 5), 
implementing the planarity test (and identification of permutations within an embedding) 
in linear time. Additionally, it will show that, given a specific permutation of those 
segments that can be permuted that an embedding can be generated in linear time. 

• The final section will present an experimental analysis (Chapter 7) of the algorithm to 
further demonstrate the algorithm's linear run time and will draw the conclusions from 
the previous sections together to show the overall efficiency of the algorithm. 



1.3 



Thesis Outline 



Chapter 2 



A History of Planarity Testing and 
Embedding 

The use of graph drawing (the visual layout of graphs) as a means to describe relationships 
has been around for millennium. It has only been in the last 350 years that graph theory 
(using mathematical abstractions to solve graph problems) has begun to introduce mathematical 
processes into the field. 

The earliest explicit forms [42, 43] of graph drawing were probably Nine Men's Morris games 
[56] found on roof slabs in a temple began by Rameses I (1400-1366 B.C.). Other examples of 
early graphs include depictions of family trees where descriptions of such trees occur as far back 
as the Roman era but the earliest surviving examples date from the 11th Century. 

The transition between early and modern graph drawing was probably marked by Leibniz's 
(1646 - 1716) new kind of geometry "Geometria Situs" (later to be called topology). In his 
letter of September 8th 1679 to Huygens, he describes it as a "new characteristic, completely 
different from algebra, which will have the great advantage to represent to the mind exactly and 
naturally, though without figures, everything which depends on the imaginations" [46]. 

The planarity problem is to find out if for a given undirected graph, a graph can be drawn in the 
plane without any edge crossings. The planarity problem was characterised by Kuratowski [44], 
in 1930, when he proved that every non-planar graph contains a sub-graph that upon removal 
of degree two vertices is isomorphic to a complete graph on five vertices (K 5 ) or to a complete 
bipartite graph on six vertices (-^3,3) • Conversely, no planar graphs contain either of these 
graphs. Although this gives a simple solution to the planarity problem, testing these conditions 
is of no practical value as Hopcroft and Tarjan [32] (H&T) state an algorithm designed to find 
these graphs would be 0(V 6 ). 

Instead of looking for the Kuratowski graphs, the current best approach is to attempt 
to construct a representation of a planar embedding of the graph, building the graph up 
incrementally until either the graph is completely embedded or a non-planar element is identified. 
The first such algorithm was proposed by Auslander and Parter [2] in 1961. The algorithm 
removed a cycle from the graph causing it to fall to pieces and then starting from the cycle, 
pieces were reattached recursively until the graph was rebuilt (planar) or a piece was obstructed 
(non-planar). Unfortunately the algorithm contained an error allowing an indefinite loop and 
Goldstein [26] later (1963) correctly formulated algorithm, using iteration instead of recursion. 
Later implementations of this algorithm have been shown to have 0(V 3 ) time-complexity, where 
V is the number of vertices in the graph. 
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Alternate methods have been presented including Lempel, Even and Cederbaum's [47] (1966) 
algorithm for vertex addition, which builds the graph from a single vertex by adding incident 
edges and repeating using careful ordering of the vertices. Although they gave no implementation 
or time-bound for the algorithm it has been shown that it can be impleme nted in 0(V 2 ) time. 
Mondshien [55] also proposed an 0(V 2 ) algorithm for adding a single vertex at a time until the 
entire graph was constructed, again relying on careful ordering of the vertices. 

H&T [31] , using depth-first search and a complicated program devised a variant of Goldstein's 
algorithm to run in 0(V ■ log (V)) and subsequently discovered an improved algorithm with 0(V) 
time complexity, which appears in Tarjan's [72] dissertation. H&T [32] further simplified their 
algorithm in 1974, producing what is acknowledged as the first linear-time planarity test. 

A second linear algorithm developed by Booth and Lueker (B&L) [5], using PQ-trees, in 1976 
was the next seminal work in the field and these two have formed the basis on which most 
further 0(V) algorithms have built. Both, H&T and B&L's approaches have had subsequent 
papers to simplify, extend or improve those algorithms, including: 

• Williamson [84, 85] and Mehlhorn, Mutzel, and Naher's [52-54] extensions to H&T's 
algorithm to generate Kuratowski sub-graphs and a planar embedding (respectively); 

• Kocay's [41] graph theoretical analysis of H&T algorithm; and 

• Work extending/improving B&L's algorithm such as: 

— Chiba et al's [14] extension to generate an planar embedding; 

— A method using PC-Trees, initially proposed, by Shih and Hsu [68] (although not 
addressing important implementation issues [29, pg. 2[) and subsequent, incorrectly 
formulated, revisions in [33-35, 69] before a correct algorithm was presented, and 
later expounded upon, by Boyer et al. [7, 12]; and 

— A similar algorithm by Boyer et al [9-11, 13] also using PC-Trees; and 

— A more recent PQ-tree algorithm by Haeupler and Tarjan [29] which, although only 
outlined, asserts a method of using PQ-trees in a similar fashion to PC-trees and of 
representing all possible embeddings of a biconnected graph. 

A more detailed investigation of the most prominent work will be pursued below. 
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2.1 Euler Characteristic 1752 



Leonard Euler (15th April 1707 - 18th September 1783) [22] is one of the pre-eminent and 
prolific Mathematicians of the 18th century. In 1736, he solved the Seven Bridges of Konigsberg 
problem by proving that there was no Eulerian Circuit when trying to walk around the city 
of Konigsberg by only crossing each bridge once. He generalised the problem by proving that 
there would be an Eulerian Circuit (a path visiting each vertex only once) for a graph if all the 
vertices, except the start and end points, have an even degree. This is considered to be the first 
theorem of graph theory and, more specifically, the first planar graph theorem. Euler's work, in 
1752, developing the Euler Characteristic and the Euler Formula became a foundation stone in 
the field of topology. 

For a finite connected planar graph 9 (V, £) (with set V of vertices and set £ of edges) and a 
corresponding planar embedding (with set of faces) on a surface (with genus 1 0) then Euler's 
Formula (alternately known as Euler's Polyhedral Formula) defines the relationship between the 
number of vertices, edges and faces such that: 

|V| - |£| + |5F| = 2 (2.1.1) 

Poincare [59] generalised Euler's polyhedral formula for other surfaces such that, given a surface 
with genus g then: 

\v\-\£\ + m=x(g) (2.1.2) 

Where \ (fl 1 ) is the Euler Characteristic of that surface and is given by: 



X (g) — 2 — 2g (For an orientable surface; i.e. the surface of a sphere or torus.) ^ ^ 
X (g) = 2 — g (For an non-orientable surface; i.e. the surface of a Klein bottle.) 

For the remainder of this work, it shall be assumed that any planar embedding is in an orientable 
plane of genus (R 2 plane or the surface of a sphere) and Euler's Formula (rather than Poincare's 
generalisation) applies. 

Euler's Formula gives rise to one of the basic tests for non-planarity: for a maximal planar 2 
graph then all the faces are bounded by three edges (triangular) and each edge connects to two 
faces; hence, 3 l^l = 2 |£|). Therefore, any simple planar graph, with |V| > 3, then the upper 
bound for the number of edges |£| is: 



|£|<3|V|-6 (2.1.4) 
Therefore any simple planar graph exceeding this limit is non-planar. 



1 The genus of a surface is, roughly, equal to the number of holes in that surface; i.e. the infinite two-dimensional 
plane, R 2 , or the surface of a sphere have genus and the surface of a torus has genus 1 

2 A maximal planar graph is a simple graph with a planar embedding having the additional characteristic that 
no edge can be added to the graph without making the graph either non-simple or non-planar. 
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2.2 Tremaux's (Depth-First Search) Algorithm 1882 

In 1882 Lucas published Recreations Mathematiques [51] containing an algorithm by Monsieur 
Tremaux to find the solution for any maze (or investigate all passageways and junctions then 
return to the maze's entrance) without traversing any passageway more than twice. Tremaux's 
algorithm is (and, may be, the first published example of) a Depth-First Search (DFS) algorithm. 
A summary of Tremaux's algorithm is given below: 

i \ 
Given a maze (graph) composed of a set of passageways (edges) terminating at 

junctions (vertices) or dead— ends (vertices with only a single adjacent edge) 

then progress through the maze can be tracked by marking the ends of each 

passageway , using the markers : 

• "In" (denoting a journey inbound along that passage to that junction); 

• "Out" (denoting an outbound journey along that passage); and/or 

• "First" (denoting the passageway first used to reach that junction). 

Tremaux uses the marking system, on passage entrances , such that: "First" is 
denoted by a single line (and all other markers are ignored); "Out" is denoted by 
a cross (two lines); and "In" is not given a notation as that entrance is , 
immediately, additionally marked as either "First" or "Out". 

On arriving at a junction along a passageway: mark the exit to that passage with 
an "In" marker; and if the exit to the passage travelled is otherwise unmarked, 
and all other passages from that junction are also unmarked, then additionally 
mark the passage with a "First" marker. 

On departing from a junction , mark the entrance to the chosen passageway with an 
"Out" marker. The passage chosen to depart from a junction is , in order of 
preference (passages marked with "Out" are never followed a second time): 

• A passageway marked, solely , with "In"; 

• A randomly selected unmarked passageway; 

• The passageway marked as "First". 

I J 

Unfortunately, while the algorithm was correctly formulated, the proof provided by Lucas was 
deficient [3]. 



2.2.1 Tarry's Algorithm - 1895 

In 1895, Tarry [74] [3, English Translation] published an algorithm is based on the similar 
principle: 

"Do not return along the passage which has led to a junction for the first time unless 
you cannot do otherwise. " 

Tarry is sometimes quoted [15] as having republished Tremaux's algorithm, however, this is not 
the case. The differences from Tremaux's algorithm are summarised below: 



Tarry uses the marking system, on passage entrances, such that: "First" is 
denoted by a three lines (and "In" and "Out" markers are ignored) ; "Out" is 
denoted by a two lines (and any "In" marker is ignored); and entrances marked, 
solely , with "In" are denoted by a single line. 



On departing from a junction , mark the entrance to the chosen passageway with an 
"Out" marker. The passage chosen to depart from a junction is , in order of 
preference (passages marked with "Out" are never followed a second time): 

• A randomly selected passageway from those passages that are either unmarked 
or marked, solely , with "In"; 

• 

• The passageway marked as "First". 
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Both algorithms find solutions to any maze by traversing each edge at most twice; however, 
Tarry's algorithm prefers to follow paths randomly selected from the set of unmarked paths and 
paths marked, solely, with "In" whereas Tremaux's algorithm prefers to follows paths marked, 
solely, with "In" and only if no such paths exists then to follow a randomly selected unmarked 
path. Since, if paths marked "In" are chosen prior to unmarked paths then, Tarry's algorithm 
can generate the same result as Tremaux's; therefore Tremaux's algorithm is a specific sub-class 
of Tarry's algorithm and proof Tarry's algorithm solves any maze (as given by Tarry [74]) also 
holds for Tremaux's algorithm. 

2.2.2 Tremaux Trees 

The edges of a graph can be partitioned into the sets of tree, cotree and cross edges such that: 

• The set of Tree edges forms a spanning tree of the graph. A partial order relationship can 
be defined over the set of vertices such that vertex u is defined to be related to vertex v 
(as an ancestor or equal to) if there is a path of Tree edges containing u between v and a 
given vertex rooting the spanning tree (typically defined to be the vertex first processed by 
the algorithm generating the spanning tree). In terms of Tremaux's, or Tarry's, algorithm 
then each Tree edge has one end marked "First" (and the vertex at the end not marked 
"First" is an ancestor of the vertex at the end marked "First"). 

• The set of Cotree edges are those non-Tree edges (where neither edge is marked "First") 
such that the terminating vertices of each Cotree edge are related; and 

• The set of Cross edges are those non-Tree edges (where neither end is marked "First") such 
that the terminating vertices of each Cross edge are not related (instead those vertices are 
in divergent branches of the rooted spanning tree) . 

A rooted spanning tree of a connected graph is defined to be a Tremaux Tree (alternately known 
as a Depth-First Search Tree) if, and only if, all non-Tree edges of that graph are Cotree edges; 
hence, for a Tremaux Tree, the terminating vertices of every edge are related since all edges are 
either Tree or Cotree edges). 

Bondy and Murty [4, pg. 141-142], amongst other graduate text-books, show 3 (using two time 
functions corresponding to the time vertices are first and last visited) that given a spanning tree 
generated by traversing a connected graph using a DFS (Tremaux's) algorithm then all vertices 
terminating edges of that graph share an ancestor-descendant relationship; hence, the spanning 
tree is a Tremaux Tree. 

In contrast, Tarry's algorithm can generate all three types of edges whilst, as an aside, (and 
assuming the additional constraint of a graph without looping edges 3 ) a Breadth-First Search 
(BFS) algorithm generates only Tree and Cross edges. 

Tremaux (DFS) Trees (and BFS-trees) are used extensively within many graph related 
algorithms, a sample of which (relating to planarity testing) are discussed later in this chapter. 
This is due to: the invariant properties of these trees (some of which are detailed, for 
Tremaux Trees, in Chapter 3); and linear time and memory implementations of DFS (and 
BFS) algorithms. 

3 Bondy and Murty's proof only considers non-looping edges; however, all looping edges are Cotree edges since: 
every vertex is contained within the path of Tree edges from the root vertex to itself so every vertex is related 
to itself; and that Tremaux's algorithm will not mark either end of a looping edge with "First" (as the looping 
passageway's entrance will have been marked prior to testing for unmarked passageways upon reaching the loop's 
exit). 
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2.3 Jordan Curve Theorem - 1887 

The Jordan Curve Theorem establishes 4 that, within the plane 
R 2 , a Jordan curve formed by two Jordan arcs A and B (which 
both terminate at points p and q but do not otherwise intersect) 
then: 

1. The complement R 2 \(A U B) can be partitioned into 
two distinct components: the (unbounded) set of exterior 
points; and the (bounded) set of interior points. Given a 
point x £ R 2 \(AUB) then there exists an upward-directed 
ray emanating from x and the crossing parity of that ray 
and a Jordan arc is whether the ray crosses the arc an odd 
or even number of times. Considering the crossing parities 
for the ray emanating from any point relative to the arcs A 
and B then it is an exterior point if the parities are equal 
and an interior point if the parities are unequal; 

2. Both components are non-empty (the interior can be shown to contain an incircle with 
non-zero radius and the exterior is unbounded); 

3. All points within each component are path-connected; and 

4. The pair of components are disconnected such that A U B is their common boundary. 




B 

Figure 2.3.1: Rays 
Intersecting a Jordan Curve 



Figure 2.3.1 gives a graphical representation of a Jordan curve formed by two Jordan arcs, 
A and B, and five points within the complement and their corresponding upwards directed 
rays. Each point and corresponding ray is coloured: in red, when the ray's crossing parities are 
unequal, representing an interior point; and in blue, when the ray's crossing parities are equal, 
representing an exterior point. 



A corollary [30, pg. 49] to the Jordan Curve Theorem is that given 
Jordan arcs A, B and C, which have the same endpoints but do 
not otherwise intersect, then the Jordan arc A (respectively B, C) 
partitions the component of the Jordan Curve B U C (respectively 
A U C, A U B) containing that arc into two distinct connected sub- 
components separated by that arc. 

Hopcroft and Tarjan [32, pg. 551-552] state a further corollary: 
given the arcs A, B and C, as previously described, then if the 
clockwise orientation of the arcs about p are in the order (A, B, C) 
then the clockwise orientation of those arcs about q is in the order 
(A,C\B). 

Figure 2.3.2 gives a graphical example of both of these corollaries 
such that A (respectively B, C) partitions the exterior (respectively 
interior, exterior) component of the Jordan curve BUC (respectively 
A U C, BUC) into two regions and that the arcs have the theorised 
clockwise orientations about p and q. 



A 




C 

Figure 2.3.2: Three Non- 
Intersecting Jordan Arcs 
With Shared Endpoints 



4 In the words of Jordan [39, pg. 99], "II est done etabli que toute courbe continue C divise le plan en deux 
regions, I'une exterieure, V autre interieure, cette derniere ne pouvant se reduire d zero, car elle contient un 
cercle de rayon fini." 
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2.3.1 Historical Note on the Correctness of 
Jordan's Proof 

Guggenheimer [28] and Hales [30] both provide a commentary on Jordan's proof and the 
subsequent proofs. However, they consider them from different perspectives: Guggenheimer 
gives a brief overview of the methodology used and their shortcomings; whereas Hales discusses, 
as a prelude to the main body of his work, the dissatisfaction within some of those papers with 
regards to Jordan's original proof. 

Guggenheimer [28, pg. 194] notes that Jordan does not prove the theorem as he omits the 
proof in the simple case of polygons 5 and that Jordan's proof of existence of two polygonal 
approximations to a Jordan Curve (within and without that curve) that are within a sufficiently 
small maximum distance from that curve (which later parts of Jordan's proof rely upon) is not 
convincing. However, he does note that the latter issue is filled by Young & Young in their 
1906 paper "The Theory of Sets of Points" and Hales notes [30, pg. 46] the former was "widely 
regarded as completely trivial" with proofs of it appearing in undergraduate textbooks. 

Hales notes similar comments from Veblen [77] 6 (who is often referenced, see [3, pg. 141], as 
having produced the first correct proof of the Jordan Curve Theorem) and Osgood 7 , who notes 
that Jordan's proof is correct only only under the assumption of its correctness for polygons 
and that Jordan's proof contains assumptions. Hales goes on to quote a private correspondence 
from Reeken that "Jordan's proof is essentially correct. . . Jordan's proof does not present the 
details in a satisfactory way. But the idea is right and with some polishing the proof would be 
impeccable". 

The major subject of Hales' work is not the critique of the treatment of Jordan's proof but an 
up-to-date version of Jordan's proof; highlighting, contrary to many [30, pg. 45], the validity of 
Jordan's methodology. So: whilst the first rigorous, and axiomatic, proof of the Jordan Curve 
Theorem can be attributed to Veblen; Jordan's original methodology can be used to prove his 
theorem. 



5 "He [Jordan] accepts as obvious that a simple closed polygon separates the plane into two regions in which 
two points can be joined by a polygonal arc without crossing the polygon but that any polygonal arc joining two 
points in distinct regions must cross the polygon." 

6 "[Jordan's proof] is unsatisfactory to many mathematicians. It assumes the theorem without proof in the 
important special case of a simple polygon and of the argument from that point on, one must admit at least that 
all details are not given" 

7 u Es sei noch auf die Untersuchungen von C. Jordan verwiesen, wo der Satz, unter Annahme seiner 
Richtigkeit fur Polygone, allgemein fur Jordansche Kurven begriindet wird. Jordan beweist hiermit mehr als 
die Funktionentheorie gebraucht; dagegen macht er Voraussetzungen, welche diese Theorie streng begriindet 
wissen will" 

8 Reeken is a co-author of the 1996 paper "A non-standard proof of the Jordan curve theorem", using similar 
methodology to Jordan's original proof 
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2.4 Kuratowski's Theorem — 1930 

Kuratowski [44] gives a characterisation of non-planar graphs such that: 9 for a connected non- 
planar graph which has only a finite number of circuits, then that graph contains a sub-graph 
homeomorphic to a 3 graph or a K$ graph. Conversely, no planar graph contains a sub-graph 
homeomorphic to either of these graphs. 




(a) Graph Homeomorphic to (b) Graph Homeomorphic to 
K 5 K 3 , 3 

Figure 2.4.1: K$ and ^33 Non-Planar Graphs 



Hopcroft and Tarjan state [32, p. 550] that " [ajlthough elegant, Kuratowski's condition is useless 
as a practical test of planarity; testing for such subgraphs directly may require an amount of 
time proportional to at least V 8 , if not much worse, where V is the number of vertices in the 
graph". They go on to conclude that " [tjhe best approach to the planarity problem seems to be 
an attempt to construct a representation of a planar embedding of the given graph. If such a 
representation can be completed then the graph is planar; if not, then the graph is nonplanar". 

Subsequent algorithms [8, 11, 17, 84] have taken this approach full circle; using the failure to 
construct a planar embedding to locate a sub-graph homeomorphic to K§ or K33 in linear-time. 
However, Hopcroft and Tarjan's conclusion about the inefficiency of testing for non-planarity by 
directly searching for such sub-graphs has not (to the knowledge of the author) been refuted. 



9 In the words of Kuratowski [44, pg. 278]: " Theoreme A. A etant un continu Peanien gauche qui ne contient 
qu'un nombre fini de courbes simples fermees, A contient une courbe homeomorphe a la courbe de la fig. 1 
ou a celle de la fig. 2 [K$]." 
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2.5 Hassler Whitney - 1932 & 1933 



Whitney contributed much to the field of graph theory; particularly relating to graph colouring, 
graph isomorphism, non-separable graphs and graph duals. Of particular interest, regarding 
planar graphs, are two theorems: the first is a characterisation of planar graphs such that a dual 
exists for all planar graphs; and the second relates to 2-isomorphic graphs. 

In 1932, Whitney published his paper "Non-Separable and 
Planar Graphs" [81] proving the theorem that: 

A necessary and sufficient condition that a graph 
be planar is that it have a dual. 

For a graph 9 (V, £) with an embedding consisting of a set 
of faces then its dual is the graph S'(V, £') with set 3* of faces 
such that there is a bijection (one-to-one correspondence) 
between: 3~ and V; V and and £ and £'. A dual graph has 
an inverse such that 9 is the dual of 9'- Figure 2.5.1 gives an 
example of a graph (vertices coloured blue and edges black) 
overlaid by its dual (coloured red). 

This theorem gives an alternate and equivalent characterisation of planarity to Kuratowski's 
theorem. 




Of particular relevance to the subject of permutations of graph embeddings is Whitney's 1933 
publication "2-Isomorphic Graphs"; this introduces Whitney's 2-Isomorphism Theorem which 
gives the conditions for two graphs to be isomorphic 10 and gives rise to the operation known 
as a " Whitney flip" (which generates a permutation of the embedding of a 2-separable planar 
graph). 

Given a partition (£', £\£') on the set £ of edges of a graph S(V, £), such that both sub- 
graphs induced by those partitions are non-empty and connected, then this is a k-separation if 
there are exactly k boundary vertices incident with £' and £\£'. Given an embedding T of 9 
containing a 2-separation (£', £\£') then a Whitney flip is an operation which removes £' from 
r and re-embeds the mirror image (re-attaching £' at the two boundary vertices), generating a 
permutation of the embedding. The corresponding effect this operation has on the dual graph 
is known as a Whitney twist. 




Figure 2.5.2: Example of a Whitney Flip 



A corollary to Whitney's 2-Isomorphism Theorem 11 is that any 3-connected graph has a unique 
embedding (since no 2-separation of that graph exists so no Whitney flips can be performed, 
hence, there are no permutations of the embedding). 

10 In the words of Whitney [81, pg. 245]: "[T]wo graphs G and G' are 2-isomorphic if one can be transformed 
into the other by operations of the following two types: (2) The arrangement of the components in the graph is 
altered. (3) If G = Hi + Hi, where Hi and H2 have just the vertices a and b in common and these vertices are 
connected in both Hi and H2, then Hi is turned around at these vertices." 

11 [81, pg. 246] " COROLLARY. If G and G' satisfy the conditions of the above theorem and one of them is triply 
connected, then both are, and the two graphs are strictly isomorphic." 



CHAPTER 2. A HISTORY OF PLANARITY TESTING AND EMBEDDING 



13 



2.6 Lempel, Even, and Cederbaum's 0(V 2 ) Vertex Addi- 
tion Planarity Test 1967 

Lempel, Even, and Cederbaum's algorithm [47] tests for planarity on a biconnected graph 
9 (V, £). The algorithm is a two stage process: 

1 . An si-order (described below) is generated for the set of vertices; and 

2. Planarity is tested vertex- by- vertex such that properties of the Bush Form (as described 
below) of the connected planar sub-graph 5k (induced by vertices with si-numbering 
1 . . . k) can be used to determine the existence of a planar embedding (and corresponding- 
Bush Form) of S(fe+i) • 

2.6.1 si-ordering 

Given a biconnected graph 9 (V, £) with an edge {s,i} € £, in an si-ordering of 9, then: s 
receives number 1; t receives number |V|; and each other vertex receives a unique number such 
that it is adjacent to a lower-numbered and a higher-numbered vertex. Even and Tarjan [23] 
show that it is always possible to find an si-numbering for a biconnected graph. 

The following properties exist regarding the sub-graph 5 k (of graph 9), induced by vertices 
Vi . . .v k with corresponding si-numbers : 

• 9fe is connected, since each vertex (except v\) connects to a lower si-numbered vertex; 

• (9 — 5k) is connected, since each vertex (except v\y\) connects to a higher si-numbered 
vertex; and 

• Given the previous two properties and a planar embedding T of 9 then considering the 
sub-embeddings Tfe and (r — r&) of 5k and (9 — Sfc)> respectively, then all elements 
of (9 — 5k) must be contained within a single face of Tfe (otherwise there is an edge 
crossing, contradicting the fact that the embedding is planar) which can be designated 
as the external face. It follows that all vertices (including v^) in 5k that are adjacent to 
vertices in (9 — 5k) must be on the boundary of this external face. 

2.6.2 Bush Form 

This final property of si-orderings gives rise to a visualisation, known as a Bush Form (23J, of 
the planar embedding of 5k composed of: 

• Tfe (oriented such that (r — Tk) could be contained in the external face); 

• All edges in (9 — 5k) connected to a vertex in 5k (designated as virtual, or half, edges), 
embedded in the external face; and 

• A virtual vertex for each disconnected end of a virtual edge (assigned the si-number 
corresponding to the vertex in (9 — 5k) that edge would connect to). 

The edges of the Bush Form can be given directionality outbound from (inbound to) the lower 
(higher) si-numbered connected vertex. Commonly, Bush Forms are visualised (see Figure 2.6.1) 
such that virtual vertices are positioned in a horizontal line above, with virtual edges ascending 
from, the embedding of 5k- 
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Figure 2.6.1 shows a sample si-ordered planar graph and examples of the corresponding Bush 
Forms for successive sub-graphs. 




6 5 3 3 4 6 
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(a) si-ordered graph (b) 23 2 of (a) 



(c) £3 of (a) 



(d) 2S 4 of (a) 



(e) S 6 of (a) 



Figure 2.6.1: Sample Planar Graph and corresponding Bush Forms 23 2 . . . 23 5 



The edges of a graph can be partitioned into distinct pieces such that each piece is a bridge 
edge or a maximal biconnected component; these pieces form a tree (since any cycle involving 
multiple pieces means those pieces were not maximal). Within the Bush Form: the embedding 
of each biconnected piece can be flipped, reversing the cyclic order of vertices on the external 
face of that piece; and the cyclic order of the embedding of pieces outbound from a given vertex 
can be permuted. Using this, the cyclic order of the virtual edges (and vertices) of a Bush Form 
can changed via a sequence of flips or permutations of the pieces. 

Lempel, Even, and Cederbaum [47] show that given the (planar) Bush Form H k then 23 fc+1 can 
be formed (and is planar) if, and only if, there is a sequence of flips or permutations of the 
embedded pieces of H k such that all virtual vertices labelled Vk+i are consecutive within the 
cyclic order of virtual vertices. 

This process, of generating an si-order then using the inductive loop of reordering the embedding 
and coalescing consecutive virtual vertices to append successive si-ordered vertices in a planar 
manner to the embedding, forms the basis for Lempel, Even, and Cederbaum's algorithm. A 
non-planar graph is found when an inductive step is reached where it is impossible to reorientate 
the Bush Form such that the virtual vertices with the next si-number are ordered consecutively 
within the cyclic order of virtual vertices. 



4 5 4 5 4 5 




(a) K 5 Graph (b) 2J 3 of K 5 (c) K (m Graph (d) S 4 of K (3i3) 



Figure 2.6.2: Non-Planar Graphs K§ and -^(3,3) and their corresponding Bush Forms. 



Figure 2.6.2 gives an example of K 5 and K 3 3 and their Bush Forms. The Bush Form 23 3 of 
-K5 has three permutable pairs of virtual vertices labelled 4 and 5 around a biconnected piece; 
at most, only two of the three virtual vertices labelled 4 can be consecutive within the cyclic 
order and therefore the inductive step to generate 23 4 fails. Similarly, the Bush Form CB 4 of K3 3 
contains four virtual vertices each connected to different vertex on a biconnected piece such that 
the si-numbering of those virtual vertices alternates; therefore the only reordering possible is 
flipping the biconnected piece and, again, the inductive step fails. Therefore, in both cases, the 
graphs are declared non-planar. 
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2.7 Wagner's Conjecture (Theorem) - 1970 

An undirected graph "K is a minor of the graph S if there exists a graph S', isomorphic to !H, 
which can be formed from the transformation of S through zero or more edge deletions and/or 
edge contractions (the deletion of an edge whilst simultaneously coalescing its two incident 
vertices to form a single replacement vertex) . 

Wagner's conjecture [79] (now Wagner's Theorem [65, 66]) is a characterisation of planarity 
relating to forbidden minors and asserts that the family of planar graphs does not contain any 
graph which has K§ or 3 as a minor. 

The Robertson-Seymour Theorem [66] is a generalisation, and proof 12 , of Wagner's conjecture; 
it asserts that every minor-closed 13 family of graphs can be defined by a finite set of forbidden 
minors (graphs that are not minors of any graph in ?) . 




Figure 2.7.1: Example of a K 33 Graph Minor 



12 Proved via a series of 20 papers culminating with [66]. 

13 A minor-closed family ? of graphs is such that for every graph in 3^ then any minor of those graphs is also in 
J. 
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2.8 Hopcroft and Tarjan's Path Addition Planarity Test 
1974 

Hopcroft and Tarjan's (H&T) algorithm developed from an earlier algorithm proposed by 
Auslander and Parter [2] (whose algorithm contained an error inducing an infinite loop and 
a correct implementation was provided by Goldstein [26]). In 1971, Hopcroft and Tarjan 
[31] formulated a 0(Vlog(V)) time bounded variant of Goldstein's algorithm which they later 
improved to 0(V) in Tarjan's dissertation [72] and simplified in their 1974 paper "Efficient 
Planarity Testing" [32] (although corrections to their algorithm were later published by Deo [21] 
in 1976). 

Of note, to this time line, is the (independently derived) 1964 paper of Demoucron, Malgrange, 
and Petruiset [20] ; who presented an algorithm with a similar premise (of separating the graph 
into a cycle and forest before recursively separating each tree of the forest into sub-forests) as 
Auslander and Parter's but, alternatively, tests planarity by locating faces which can accept a 
valid embedding. 

The H&T algorithm takes a biconnected graph (however Tarjan [73] gives a linear-time algorithm 
for separating a connected graph into its biconnected components) and processes it using a three 
phase process: 

In the first phase, a Depth-First Search (DFS) is performed over the graph generating a palm 
tree (alternatively known as a DFS-tree or a Tremaux Tree) and assigning: each vertex a DFS- 
index; and categorises each edge as either a tree or a frond edge (also known as a back or cotree 
edge) and gives it a direction. During backtracking, the algorithm calculates, for each vertex, the 
lowest, and second lowest, indexed vertices reachable using the descendant portion of the palm 
tree. These pieces of information are then used: to bucket sort the edges; create a adjacency list 
of all edges outbound from each vertex; and, within the last phase, to compare paths generated 
in the second phase to test for non-planarity. 

The second phase involves a second DFS, considering only the (now directed and sorted) 
outbound edges from each vertex; first identifying a cycle within the (biconnected) graph then, 
as the DFS backtracks and follows new branches, identifies successive paths. The result is that 
the graph is partitioned into edge-disjoint paths. 

The final phase takes these paths, in order of generation, and considers their embedding. The 
first path is a cycle which separates the embedding into two faces. Paths branching from that 
cycle connect to it at two distinct points and, if planar, can then be embedded on one side of 
that cycle or the other; those paths then define their own cycle and paths branching off that 
new path can then be recursively considered relative to the cycle it forms. As each successive 
path is considered for embedding, if it overlaps a previously embedded segment then it must be 
on an opposite side of the cycle it branches from compared to that previous segment. 

H&T use two stacks, designated as left and right, to represent the sides of a separating cycle 
upon which paths can be embedded and a third stack of blocks of paths. A block represents a 
group of paths on the left and right stacks where the positioning of any one of those paths on 
the left or right stack determines the position of all other paths in that block to be on the same 
or the opposite stack; moving one path of a block from the left to right (or vice versa) swaps the 
stacks for all paths. Using this, the problem of embedding the graph is reduced to a sequence 
of simple tests and stack manipulations such that: 

• Each successive path is considered against the blocks on the stack such that if a block 
determines the position of that new path (i.e. the last path of that block on the left or 
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right stack overlaps with the new path) then the last block is removed from the blocks 
stack: if both the left and right paths overlap then the graph is non-planar; if the left path 
overlaps then the paths of that block are swapped between left and right stacks and the 
previous block is considered; and if the left path does not overlap then the position of the 
paths on the stack remains unchanged and the previous block is considered. This process 
loops until either a block is found that does not overlap on either side or a non-planar case 
is found. If no non-planar state is reached then the new path is added to the left stack 
and a new block is formed of this new path and all paths in the deleted blocks. 

• If a state is reached where the path at the top of a stack has no influence on the embedding 
of the next path then it can be removed from the stack, and block (which if that was the 
last path in the block then the block can also be removed from the stack of blocks), and 
the embedding can be considered against the previous path on that stack; 

• An additional process is required when the algorithm 
backtracks to a point where all the paths separated by 
a cycle (as defined by the embedding of each path) 
are processed. At this point the blocks containing 
paths branching from this cycle are considered, having 
removed paths from blocks which have no influence on 
the embedding, and if a block contains paths on both the 
left and right stacks (Figure 2.8.1)then the graph is non- 
planar; if there are only paths on the left stack (the case 
never arises where there are just paths on the right stack) 
then those blocks are merged with the previous block since 
subsequent paths may overlap. 



t 

Figure 2.8.1: Paths (Green 
and Blue) on Left and Right 
of Cycle (Red) Formed by 
Path (x -> y -> z). 



2.8.1 Example of H&T's Algorithm 



Figure 2.8.2 is an example graph (taken from [32, pg. 554]) that shows the order in which the 
depth-first search, of the first phase of H&T's algorithm, visits vertices (ascending alphabetical 
order) and edges (ascending numerical order). The paths formed during the second phase are 
shown in figure 2.8.3 and are numbered in ascending numerical order of the order they are 
generated. 




Figure 2.8.2: Example Graph and Sample 
Path Taken by DFS 



® 

A 
© 



or 



Figure 2.8.3: Disjoint Paths Generated by 
Second Phase of H&T's Planarity Test 
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Figure 2.8.5: Contents of Stacks during Embedding of Figure 2.8.2 

Figure 2.8.4 shows the process of embedding the paths and figure 2.8.5 shows the corresponding 
state of the stacks with two columns representing the left and right stacks (showing the numbered 
paths from figure 2.8.3 rather than the path's end vertices as in [32, pg. 562]) and horizontal 
groups representing the blocks. 

• (a) embeds the first (cyclic) path (adding it to the left stack) defining an inside (tan) and 
outside (brown) face. The second path is then embedded (adding it to the left stack and, 
since it does not overlap a previous path, a new block). 

• The cycle formed by this second path defines two faces (tan and brown shown in (b)) and 
within that the third and fourth paths can be embedded. Neither path overlaps another 
so they are both added to the left stack (which corresponds, at the moment, to the inside 
face) and each to a new block. 

• (c) shows the embedding of the fifth path; this path overlaps the fourth (red) path (but 
not the third) and results in the paths of that block being swapped from left to right, and 
vice versa, (the result of swapping the fourth path is shown in black) and then the fifth 
path being embedded to the left stack and to that swapped block. 

• Considering (d): the algorithm backtracks to vertex M, the end of the fourth path which 
then has no further effect on the embedding process and is removed from the stack; at 
vertex L, the algorithm has backtracked to the start of the second path and all the blocks 
of branching paths (the third and fifth paths) are merged into the same block as the second 
path; upon backtracking to vertex K, the end of the fifth path is reached and it is removed 
from the stack; and then the sixth path is considered. The sixth path overlaps the third 
path (red) so the last block is swapped (moving the remaining second and third paths to 
the right stack and leaving the left stack empty) allowing it to be embedded. 

• The cycle formed by the sixth path defines two faces (tan and brown shown in (e)) and 
within that the seventh paths can be embedded. Neither path overlaps another so they 
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are both added to the left stack (which corresponds, at the moment, to the inside face) 
and each to a new block. 

• (f ) shows the algorithm having backtracked past the start of the sixth path (so requiring 
the the block containing the seventh path to be merged into the previous block) and past 
the end of the third path (removing it from the stacks) then the eighth path can be added 
to the left stack, without overlap, and a new block. 

• The final (ninth) path (g) overlaps the eighth path (requiring it to be swapped from the 
left to right stack and also overlaps the second path (which is already on the right stack, 
so no swap is required). After this, the ninth path can be embedded to the left stack and 
to the block formed by merging the previous two, since the both contained overlapping 
paths. 

• Upon backtracking to vertex A, the algorithm completes as all paths will then have been 
removed from the stacks. 



2.8.2 Extensions to H&T's algorithm 

H&T's algorithm only tests whether a graph is planar or not. Extensions and revisions to this 
algorithm including: 

• In 1977, Reingold, Nievergelt, and Deo [64] presented an updated version of the algorithm 
and a more detailed explanation of the testing process; 

• In 1980, Williamson [83] presented an implementation based on H&T's algorithm and 
the work of Demoucron, Malgrange, and Petruiset [20] (who presents a non-linear time 
algorithm similar to Auslander and Parter, upon which H&T's algorithm is based, that 
explicitly considers the faces generated as successive super-graphs are formed by appending 
paths - there is an implicit relationship between the planarity testing process and the 
generated faces is H&T's algorithm but it is not explored); 

• Williamson [84, 85] presented an extension to H&T's algorithm to extract Kuratowski 
sub-graphs upon failure of the planarity test; 

• Kocay [41] gives an overview of H&T's algorithm and theoretical analysis of the properties 
of the branches of the DFS tree and proof (mostly independent of an algorithmic 
implementation) that the method tests correctly for planarity; and 

• Mehlhorn, Mutzel, and Naher present a series of papers [52-54, 57] on their implementation 
of H&T's algorithm used in the LEDA graph library and its extension to generate a cyclic 
edge order for each vertex representing a planar embedding of the graph or, on failure, to 
extract a Kuratowski sub-graph. 

2.8.3 "Complexity" of H&T's algorithm 

Chiba et al. [14] commented that "the modification [of H&T's planarity testing algorithm to 
construct an embedding] looks to be fairly complicated; in particular it is quite difficult to 
implement a part of the algorithm for embedding an intractable path called a special path v . One 
of the main reasons for this issue is that, while the Left-Right stacks are so named, there is no 
correlation between a path's positioning on the Left (Right) stack and its position within an 
embedding. 

This is highlighted in figures 2.8.6-2.8.8, below. 
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• Figure 2.8.7a shows the embedding of paths 1, 2 & 3 and figure 2.8.8a shows their 
corresponding position on the (Left) stack. The paths within the yellow and brown areas 
in the embedding correspond to the highlighted paths on the stacks. 

• Figures 2.8.7b & 2.8.8b shows the embedding of paths 4 & 5 onto the Left stack; both 
of which conflict with path 3 causing it to be moved to the Right stack. The yellow and 
brown areas highlighted in the embedding are unchanged from the previous embeddings 
of paths 1-3 and still contain the correspond to the contents of the stacks. 

• Figures 2.8.7c & 2.8.8c shows the embedding of path 6, which conflicts with path 5 and 
so paths 4 & 5 are both contained in the same block and are moved to the Right stack 
(the algorithm has backtracked to the end of path 3 and it is removed from the stack) . In 
this case, since path 4 can only be within the face bounded by vertices A, B,C, D, E, F 
& G and is now contained in the Right stack, the stacks correspond to the opposite areas 
highlighted in the prior embedding stage. 




Figure 2.8.6: Second 
Example of Disjoint 
Paths (Numbered in 
Embedding Order) 
Generated by Second 
Phase of H&T's 
Planarity Test 
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Figure 2.8.8: Second 
Example - Contents of Left- 
Right Stacks Corresponding 
to Successive Embeddings 
Showing Lack of Correlation 
Between Path's Stack and 
Embedding Region 



Mehlhorn, Mutzel, and Naher [52-54, 57] show that this problem is not insurmountable. 
However, this issue has caused authors of alternate planarity tests to criticise the algorithm 
(whilst discussing their own works); this includes: Shih and Hsu [68, pg. 1], who states that 
H&T's algorithm is "quite involved" and that the "partial planar sub-graph construction [...] 
needs to be continually modified to obtain a final embedding"; and Boyer et al. [12, pg. 243], 
who note that the algorithm is "complex" (in reference to Chiba et al.'s quote). 
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2.9 Booth and Lueker's Vertex Addition Planarity Test - 
1976 

Booth and Lueker [5] published the second linear-time planarity test two years after Hopcroft 
and Tarjan. This improves upon Lempel, Even, and Cederbaum's [47] 0(V 2 ) algorithm through 
the introduction of an efficient PQ Tree data structure and the use of templates that restrict the 
permissible permutations and allows the graph to be tested for planarity such that "[i]ts time 
complexity is shown to be linear in the size of the input". 

Lempel, Even, and Cederbaum's algorithm uses Bush Form representations of successive st- 
ordered sub-graphs to test for planarity. These Bush Forms are separated into maximal 
biconnected or bridge edge pieces such that pairs of connected pieces are separated by an 
articulation vertex; the PQ Tree data structure corresponds to the Bush Form such that: 

• The leaves of the PQ Tree represent the virtual vertices of the Bush Form; 

• P-nodes represent articulation vertices, with two or more outbound pieces (children), or 
maximal biconnected pieces with exactly two outbound pieces (children); and 

• Q-nodes represent maximal biconnected pieces, with three 14 or more outbound pieces 
(children) . 

Corresponding to the transformations that can be performed on the Bush Form to reorder the 
virtual vertices, the following equivalence transformations are permitted on a PQ Tree: 

• Permuting the order of the children of a P-node; or 

• Reversing (flipping) the order of the children of a Q-node. 

Booth and Lueker given an additional status, for a PQ Tree equivalent to the Bush Form 
T> k , such that: a leaf is pertinent if it is labelled (k + 1); and a node is full / partial / empty if 
all/some/none (respectively) of its descendant leaves are pertinent. The order of children of 
nodes that are full or empty are inconsequential to determining whether the leaves labelled 
(k + 1) have a consecutive ordering. 

Using this, Booth and Lueker show that the test for planarity at any inductive step (of coalescing 
the next si-ordered leaves to add a vertex to the embedding) needs only consider the minimal 
sub-PQ Tree containing all pertinent leaves. To simplify the process, nine templates (patterns 
and corresponding replacements) are defined such that each node within that minimal sub-tree 
must match one of those patterns (otherwise the graph is non-planar) and the sub-tree can 
be reduced (and simplified) by replacing that pattern with its corresponding replacement. To 
create the PQ Tree T fe+1 from 7 k then 7 k is first reduced using the templates and then all the 
(now consecutive) leaves labelled (k + 1) are replaced by a P-node whose children are leaves 
corresponding to its adjacent vertices labelled (> k + 1). 

Chiba et al. [14] augment Booth and Lueker's algorithm to generate a planar embedding of the 
graph, also in linear time. 



14 [5, pg. 339]" [TJhere is no real distinction between a P-node and a Q-node if there are only two children. It 
is convenient to remove this redundancy"; "[. . .] guaranteeing unique PQ-tree representations for the classes of 
permutations being studied." 
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2.10 Shih-Hsu - Edge Addition Planarity Test 1999 

Shih and Hsu [69] introduce a variation on the PQ Tree data structure called a PC Tree and a 
test for planarity by successively appending edges to the embedding. 

The algorithm pre-processes the graph using Depth-First Search: partitioning the edges into 
tree and cotree (back) edges; assigning each vertex an ascending index, in post-DFS order; and 
applies an ordering the edges. 

The main body of the algorithm begins by embedding tree edges then backtracking up the DFS- 
tree until a vertex with an inbound cotree edge is reached. The algorithm then tests against a 
number of patterns, each defining non-planarity characteristics, and if none are matched then 
applies a reduction to embed the inbound cotree edge(s); this forms a biconnected component 
where: 

• The vertices adjacent only to interior faces of that component have all their incident edges 
processed and their embedding has been found to be planar so can be ignored; 

• The vertices on the boundary of the external face of that component form a cycle which 
can be represented by a C-node (defining the cyclic order of those vertices); 

• Vertices in the C-node with incident unprocessed edges are represented by P-nodes. 
attached to the C-node, and allowing the order of those unprocessed edges to be permuted; 

As branches in the DFS-tree are explored disjoint biconnected components can be formed and, 
when the algorithm backtracks beyond a branching point of the DFS-tree which joins two or 
more biconnected components, and inbound cotree edges are found, then these components can 
be coalesced. Similarly to Booth and Lueker's algorithm templates are used to restrict the order 
of P-nodes and biconnected components which do not match a pattern are non-planar. 




Figure 2.10.1: Example of the Generation of C-nodes and Their Concatenati 



Figure 2.10.1 shows: an example graph (a); the path followed by the DFS algorithm (b); the 
biconnected components (c)/(d)/(e) formed after the DFS processes the red/green/dark blue & 
orange paths (respectively) of (b) (the root of the DFS-tree for these components is shown as a 
node with a double circle) ; and (an embedding of) the biconnected component (f ) formed from 
processing the light blue path and coalescing the previously generated components. 
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The PC- Tree algorithm was originally formulated by Shih and Hsu [68] in 1993, however Boyer 
et al. note [12, pg. 130] that this original "formulation lacks a description of how to implement the 
routines that manipulate the PC-tree to solve the planarity problem". Thomas [75] presented a 
self-contained exposition on this methodology producing an (correctly formulated) algorithm 
that (in his words) "is not completely satisfactory" as it requires the (sub-) graph being 
tested to be 3-connected. Later papers by Shih and Hsu [33-36, 69] suggest clarifications and 
improvements to the algorithm but, as noted by Haeupler and Tarjan [29, pg. 2], "gave incorrect 
algorithms" . A corrected algorithm was finally published by Boyer et al. [11] (building on the 
earlier works of both Shih and Hsu and Thomas) and additional details of the non-planarity 
tests given in Boyer. 



2.11 Boyer- My r void Planarity Test 

In 1999, Boyer and Myrvold [8] published a modification of Booth and Lueker's PQ-Tree 
algorithm which uses a similar methodology to Shih and Hsu's algorithm [68]; a high-level 
overview of the algorithm is given in 2.11.1, below (from [9, pg. 8[). This has been improved 
over a series of papers [9, 10, 12, 13] 

Listing 2.11.1: High-Levcl Outline of Boyer-Myrvold Planarity Test 



(1) Receive graph S with n > 2 vertices and m < 3n — 5 edges 

(2) Perform depth first search on S and other preprocessing 

(3) Based on S , create and initialise embedding S 

(4) Add each DFS tree edge of S to S as a singleton biconnected component 

(5) For each vertex v of S in reverse DFI order 

(6) Embed in S each back edge in S from v to a DFS descendant of v. 
For each such back edge (v,w) , embed (u,u>) such that: 

a) all biconnected components are merged together that will no longer 
be separable then (v,w) is added; 

b) any vertex x with unembedded back edges to v or DFS ancestors of v 

is kept on the external face (along with cut vertices separating x from 
v). 

If embedding (v,w) requires violation of 6b, break the loop. 

(7) If one or more back edges were not embedded, Isolate a Kuratowski subgraph. 



Boyer and Myrvold use a similar (to Shih and Hsu's algorithm) reverse-DFS order to process 
vertices and to embed successive edges; however, they use a PQ-tree structure modified such 
that a Q-node is represented by a doubly-linked cycle (equivalent to a C-node in a PC- 
tree) which is rooted at the vertex with minimum DFS index, restricting the cycle from 
rotating but allowing it to be flipped - simplifying the testing process. The algorithm involves 
iteratively: testing embedded biconnected components for non-planarity patterns; embedding 
edges onto biconnected components; and if necessary, (flipping and) merging pairs of biconnected 
components. 

Boyer and Myrvold assert, based on empirical testing in [10], that (alongside [17] 's algorithm 
[17]) their implementation of this algorithm is one of the fastest implementations of a planarity 
testing algorithm. 
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2.12 De Fraysseix and Rosenstiehl's Tremaux Tree Pla- 
narity Characterisation and Test — 1982-2008 

In 1982, De Fraysseix and Rosenstiehl [18] gave a characterisation of planarity in terms of 
Tremaux (Depth-First Search) Trees that presented five patterns for the arrangement of cotree 
edges incident to the spanning tree of a Tremaux Tree. This was based on an earlier paper by 
Rosenstiehl [67] who in turn drew upon an earlier planarity criterion of Wu [87] and a planarity 
test of Liu [49] [50, partially summarised in]; they later [19] simplified this characterisation 
reducing it from five to three templates. De Fraysseix and Rosenstiehl note that Hopcroft and 
Tarjan's proof of their planarity test depends on "a lemma associated with the computing process" 
instead of a formal definition on the structure of the paths and this characterisation fills this 
gap. 

The characterisation considers the equivalence of angles formed cotree edges with the Tremaux 
Tree; it defines, based on precedence of vertices within the Tremaux Tree, three configurations 
(Figure 2.12.1) of edges (marked a and /3) such that that a pair of angles (highlighted in red 
and blue) are either classed has being the " T-alike" (a) or " T-opposite" (b and c) depending on 
whether they are on the same or opposing sides of the tree. A graph is non-planar if there exists 
a pair of edges which are characterised as both " T-opposite" and " T-alike". 



O A vertex. 

(^)A sub-tree, possibly 
reduced to a vertex. 

T A chain of one or 

C more tree edges. 

^ A chain of zero or 

v, more tree edges. 

A cotree edge. 

r 



Figure 2.12.1: De Fraysseix and Rosenstiehl's Planarity Characterisation on Tremaux Trees 

In 2006, de Fraysseix, Ossona de Mendez, and Rosenstiehl [17] published a planarity testing 
algorithm; then in 2008 de Fraysseix [15] published a simplification. Comparing this algorithm 
to H&T's: 

• Hopcroft and Tarjan pre-processes the graph to generate vertex and edge orderings before 
separating the graph into a cycle and a series of paths such that each of these paths is 
terminated by a back (cotree) edge. They then consider the embedding of these paths in a 
specific order and use two stacks to enforce the condition where paths must be embedded 
on the same or opposite sides; testing for these conditions is performed by comparing the 
precedence within the DFS (Tremaux) tree of the vertex those paths (and, correspondingly, 
back edges) are inbound to. 

• De Fraysseix uses a pre-processing phase (identical to H&T) to generate: an order over 
the vertices; directions for the edges; and calculations of low points; before creating an 
(again, identical to H&T) order on the outbound edges. He then, similarly, considers the 
embedding of the cotree edges (using this identical order) to generate an /-colouring which 
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enforces the condition that cotree edges must be T-alike or T-opposite at the vertex those 
cotree edges are inbound to. 

In both the 2006 and 2008 papers, the first phase of the algorithm is presented in great detail 
using mathematical notation whereas the second phase is sketched in less than a page. An 
implementation of the algorithm is included in the pigale library [16], however (as of version 
1.3.9) the documentation appears to consist solely of class dependency diagrams and the source 
code is uncommented. The lack of detail and clarity in all these aspects makes it very difficult to 
know exactly how the algorithm functions and whether it is an optimised (or simplified) version 
of H&T's algorithm or if it contains a novel approach. 

In either case, this does not detract from the detailed mathematical characterisation of Tremaux 
Trees that the authors have presented and the fact that, during testing of the PIGALE and LEDA 
libraries, Boyer et al. [12] noted that this algorithm provided the fastest test for planarity of all 
implementations within those libraries. 
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2.13 Planarity Algorithms via PQ-Trees 2008 

Bernhard Haeupler [29] presents 15 a new algorithm (developed in conjunction with Robert 
Tarjan) based on a simplification of the PQ and PC methodology showing that the two data 
structures are different implementations of the same methodology. 

The algorithm presented by Haeupler creates one or more PQ-Tree style structure where vertices 
can be fully, partially or not embedded. Fully embedded vertices are within the PQ-Tree, 
partially embedded vertices are at the leaves of the tree and the non-embedded vertices are 
awaiting addition to the tree. As a vertex is added to the structure if it connects to two or 
more PQ-Trees the structures are combined but permutations are not discarded unless one 
permutation would invalidate the planarity of the graph. 

The extended abstract and presentation give an overview of the methodology but does not give 
a concrete definition of the algorithm and while the process looks promising there is not enough 
detail to fully evaluate the algorithm. 

One of the interesting side points in Haeupler's conference presentation was the side note that 
there is no current path addition algorithm that can give all possible embeddings of a planar 
graph. 



2.14 Conclusions 

There are relatively few papers in the field of planarity testing and embedding as optimal 
algorithms rely on a few basic concepts (DFS-trees or BFS-trees) and it is rare that a significantly 
different approach to the field is found so most papers contain simplification or optimisations of 
a previous approach. 

In the field of Path addition the first algorithm by Hopcroft and Tarjan [32] and the later 
embedding process by Mehlhorn and Mutzel [52] are still state-of-the-art in this field. The work 
of de Fraysseix [15] is similar (and may be a simplification of Hopcroft and Tarjan's algorithm 
or may be a novel algorithm that uses some similar concepts) and has proved [12] itself to be a 
fast algorithm. 

Vertex and Edge addition are the major areas of research as the data structures are improved 
or refined and the algorithm by Boyer and Myvold [11] is considered to be the state-of-the-art 
in this category of planarity testing algorithms. The latest work by Haeupler and Tarjan [29] 
may supersede this and give a vertex addition method that generalises PQ and PC trees and 
allows all possible embeddings of a planar graph to be generated but as the extended abstract 
only presents an overview of the processes used there is not an algorithm to evaluate (nor has 
it appeared to be forthcoming). 

Given this overview of the field it is clear that there is an opening for an algorithm that can 
generate an embedding of a graph, where possible, and to give all possible embeddings of a 
planar graph in linear time. The final part of this is new and novel and does not appear in any 
of the previous algorithms. 



15 Video of the presentation is available from http : //www . canalc2 . tv/video . asp?idvideo=7543 



Chapter 3 



Tremaux Trees 



Tremaux Trees are so named after Tremaux's (Depth-First Search) algorithm which generates 
a rooted directed spanning tree with specific properties (described later in this chapter) as it 
processes an (undirected connected) graph. Various papers presented by W. Wu [87], Pierre 
Rosenstiehl [67], Hubert de Fraysseix et al. [15, 17-19], and Yanpei Liu [50] present definitions 
of Tremaux Trees and the statement that a DFS algorithm generates a Tremaux Tree. Proof 
of this statement (although not couched in terms of Tremaux Trees) can be found in, amongst 
others, undergraduate textbooks such as [4, Pg. 141-142]. 



3.1 Tremaux Tree Definitions 



The definition of a Tremaux Tree and subsequent definitions (3.1.1 - 3.1.11) relating to the 
structure of the Tremaux Tree are included below (for completeness) . The final pair of definitions 
in this section (3.1.12 & 3.1.13) are included as a clarification to de Fraysseix's work [15, 17] 
regarding conversion of a partial order of the set of edges outbound from any given vertex to 
a total order and have particular reference in later chapters when considering permutations of 
embeddings. 
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Definition 3.1.1. A Tremaux Tree (TT), 
T(S,3 r , r), defines a partition on the edge-set 
(£) of a graph S (V, £) into the set of tree 
edges (?) and cotree edges (£\J) such that: 

• The tree edges form a rooted spanning 
tree of S (rooted at vertex r) ; 

• A partial order relationship "precedes or 
equals" (^) can be defined on V such 
that x =4 V if the path within the rooted 
spanning tree, defined by J, from r to y 
includes x (and x -< y x =4 V Ax ^ y); 

• T is a Tremaux Tree if, and only if, every 
edge of 9 is incident to two comparable 
(_L) vertices (u_Li> ttii^tiVu^u). 

Definition 3.1.2. Each edge {u, v} G £ 
of a Tremaux Tree can be given directionality 
(u — > f ) where, without loss of generality: 

• If {it, v } 6 then u < v; and 

• If {it, u} G £\3 r then v ^ u. 

• (u ii ) denotes a directed tree edge. 

• (u w) denotes a directed cotree edge. 

Corollary 3.1.3. There is a bijection 
from the set of tree edges and the set of 
non-root vertices (Vu G V\{r}, 3!u G V : 
( u ^ y ) G J). 

Definition 3.1.4. The partial order ^ 
can be extended to V U £ such that: 

• The "immediately precedes" 
(-<u,) relationship can be 
defined such that u -< m v 
(u ^ v A ($x £ V U £, : u ^ x ^ «)). 

• For all (u-^>i>): u -< m (u-^>u) -< IKI v. 

• For all (u -2> w) : u =^ u -< IU (it i>) 
which terminates the branch of the 



Tremaux Tree (such that |i e V U £ 
(u-^ v) -< x). 




(L-i^A) (L-^M) (P-^B) (P-^C) 




(B-^B) 




(B-^C) 



(A^B) 

4) 



Figure 3.1.1: Example Graph with Edges 
Labelled by Depth-First Search Pre-Order 
(Tree edges are thick, cotree edges are dashed). 



Figure 3.1.2: Tremaux Tree of Example Graph 
(Figure 3.1.1) where each connection in the tree 
represents a -< relationship 
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Definition 3.1.5. Each edge's direction 
defines the vertices it is inbound to and 
outbound from; for each edge e G £ where 
e = (u — > v) then in (e) = v and out (e) = u. 

Definition 3.1.6. The edges' directions 
define mappings from each vertex to the sets 
of edges outbound from and inbound to that 
vertex; for each vertex »£V: 



(O-^+S) (O-^+M) 



• outbound (v) 

• inbound (v) 



{e G £ : out (e) = v} 
{e G £ : in (e) = v} 



Definition 3.1.7. The reachable 
elements (vertices and edges) of S from 
a given element x is the union of the set 
of elements succeeding or equalling x (the 
sub-tree of the Tremaux Tree rooted at x) 
and the set of vertices connected to edges 
within that sub-tree (which is: all vertices in 
the sub-tree; the vertices cotree edges in that 
sub-tree are inbound to; and if x is an edge 
then the vertex which x is outbound from) : 

• reachable (x) = {y G V U £ : x =4 y} U 

{in (e) , out (e) G V : e G £, x =4 e} 
= {y eVU £ : x ^ y}U {x'} U 
{in (z) : z G £\9 r , in (z) ^ x ^ z} 
x :igV 
out (x) : x G £ 



where x' 




Figure 3.1.3: Reachable vertices and edges 
(red) from edge (i M) for the Tremaux 
Tree (Figure 3.1.2) of Example Graph 



Definition 3.1.8. The low-points of a given element a; of a Tremaux Tree are the reachable 
vertices which equal or precede x: 

• lowPoints (x) = {y G reachable (x) D V : y =4 x} 

x : x G V 
[out (x) : x G £ 

• lowPoints (x) is a subset of the unique path, within from the root vertex to x. 



{x'} U {in (z) : z G £\3 r , in (z) =^ x =^ z} where x' 



Additionally, each element x has at least one low-point vertex x' and max (lowPoints (x)) = x' . 

Definition 3.1.9. The first low-point vertex is defined as the low-point vertex with 
minimum precedence. 

• lowPointl (x) = min (reachable (x)) = min (lowPoints (x)) 

Definition 3.1.10. The second low-point vertex is defined as the low-point vertex with 
the second lowest precedence; if an element only has a single low-point vertex then the second 
low-point vertex is defined to be that (maximum precedence) vertex. 

• lowPoint2 (x) — min ((reachable (x) \lowPointl (x)) U {max (lowPoints (x))}) 

x : x €.V \ 
out (a:) : x G £ 



min ((lowPoints (x) \lowPointl (x)) U {a/}) where x' 



Figure 3.1.3 shows the elements of the example graph (Figure 3.1.1) that are reachable from edge 
(L M); the first and second low-points of edge (L MJ are vertices E and J, respectively. 
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Definition 3.1.11. A TT-precedence or- 
der -<* is a partial order defined on the 
disjoint sets of edges outbound from each 
vertex. For any v G V and ei,e2 G 
outbound (v) then e\ -<* e 2 if: 

• lowPointl (ei) -< lowPointl (e.i)\ or 

• lowPointl (ei) = lowPointl (e-z) A 
lowPoint2 (ei) = v A lowPoint2 (ea) -< v 

Definition 3.1.12. For any v e V and 

ei,e2 € outbound (v) where -<* does not 
define an ordering then those edges are defined 
to have an incomparable TT-precedence order 
(||* ). This occurs when lowPointl (ei) = 
lowPointl (e 2 ) and either: 

• lowPoint2 (ei) = lowPoint2 (e^) — v; or 

• lowPoint2 (ei) -< vAlowPoint2 (e 2 ) -< v) 

Figure 3.1.4 (b) shows examples of both cases 
of incomparable TT-precedence edges: the red 
edges are examples of the first case (where the 
edges' second low-points are equal to the vertex 
the edges are outbound from); and the green 
edges are examples of the second case (where 
the edges' second low-points precede the vertex 
the edges are outbound from). 




(a) (b) 



Figure 3.1.4: (a) Edges outbound from the 
same vertex in TT-precedence order from the 
three outermost edges with (incomparable) 
lowest precedence to the innermost with 
highest precedence. (b) Two sets (red 
and green) of incomparable precedence edges 
outbound from the same vertex - the green 
edges have higher precedence than the red 
edges. 



Definition 3.1.13. For each vertex's set of outbound edges, the partial order -<* can 
be extended to a total order (<**) such that each sub-set of edges with incomparable TT- 
precedence (||*) is assigned an arbitrary ordering. 

Let {ei, e 2 , e 3 , . . . , e„} = outbound (v) such that e\ <** e 2 <** e 3 <** . . . <** e„ then: 

• Ve,-,ej € outbound (v) : i < j =>■ (e, ^* ej V(ej ||* e^Ae^ is arbitrarily ordered before e^)) 

• min** (outbound (v)) = e\ and max** (outbound (v)) = e„ 



This final pair of definitions (3.1.12 & 3.1.13) are included as a clarification to the definitions in 
de Fraysseix's paper [15]. De Fraysseix notes that the relationship (def. 3.1.11) is a partial 
order [15, pg. 172] but uses it to define a total order [15, pg. 175] on the set of outbound edges 
of each vertex. 

This is a minor point, with regards to de Fraysseix's paper, as a software implementation of 
de Fraysseix's algorithm will contain an underlying data structure used to store edges outbound 
from a given vertex (maintaining a static order for those edges) and the combination of the -<* 
partial order and the underlying data structure's order implicitly creates a total order (<**). 
However, this point is central to identifying alternate embeddings of a graph since varying (and 
controlling) the order of the edges (related via ||*) in the underlying data structure will vary (and 
control) the order in which those edges appear in the total order - definition 3.1.13 explicitly 
captures this relationship. 



Chapter 4 



Planarity Testing 



4.1 Segments of a Tremaux Tree 

The H&T planarity testing algorithm [32] considers, for a biconnected graph, a cycle containing 
the root vertex; removal of this cycle separates the Tremaux (DFS) Tree into the cycle and a 
forest of disjoint sub-trees emanating from the cycle. Each sub-tree contains a path from the 
minimum precedence edge of that sub-tree to that edge's first low point; removal of this path 
separates the sub-tree into further disjoint sub-trees. Recursively considering sub-trees then a 
path can be removed from each sub-tree separating it into successively smaller until each sub-tree 
is reduced to nothing and the graph can be considered to be composed of the set of (removed) 
disjoint paths; upon which planarity can be tested. 

H&T define a segment of the graph to be one of the recursively generated sub-trees (of the 
Tremaux Tree) and refer to the eventual output simply as paths. This use of terminology 
is solely related to the theory supporting the algorithm's correctness as to achieve a linear 
execution time the disjoint paths are generated directly and no data structure is generated to 
represent the segments; as such the paths generated by H&T's algorithm have a hierarchical 
nature corresponding to the containing nested sub-trees but this is not explicitly noted by H&T. 
To try to capture these properties, the "segment" terminology is alternately defined to be a path 
generated by this process (and so has specific properties, as described below) and the more 
generic terms of path and sub-tree can be used where its traditional meaning is expected. In 
addition, a generic term "chain" is also defined specifically relating to a path within a Tremaux 
Tree as this is useful in defining a segment and in later analysis of the properties of segments. 

The closed interval notation can be used [15, pg. 171] to represent a chain of elements (a simple 
path of elements all related within the Tremaux Tree): 

Definition 4.1.1. A chain of elements with minimum and maximum precedence elements 
u and v, respectively, (denoted by [u; v]) is defined as the (maximal) ordered (via -<) set 
containing all elements x in the Tremaux Tree where u =<I x =^ v. 

• Let (A, H) denote the sequence (totally ordered set) containing all elements in set A 
ordered by the relationship 31 then a chain can be equivalently denoted by: 

[u;v] = ({V.t e VU £ : u 4 x 4 v} ,-<). 

• Additionally, the following notations can be defined: 

}u;v] = ({V.t e VU £ : u -< x v} ,-<); 



31 
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[u;v[ 


= ({Vx e VU £ : u =«! x -< v} ,^); and 


]u;v[ 


= ({Vx G Vu£ : u ■< x -< v},-<). 


• The head (tail) of the chain 


is defined as the element within the chain with minimum 


(maximum) TT-precedence: 






head ([it; v]) = u; and 




tail ([«;«]) = v. 



A definition of a segment (defining equivalent paths to those generated by pathfinder algorithm 
used by H&T [32, pg. 556]) can be made using the concept of a chain within a Tremaux Tree: 

Definition 4.1.2. The vertices and edges of S can be partitioned into a set of segments 
such that: 



• Each segment is a chain; 

• The segments are disjoint and cover all elements of the graph - each vertex and edge is 
contained in exactly one segment; 

• For all (u v) € 1 then (u ^> v) and v are contained in the same segment; 

• For all v e V where outbound (v) ^ then v and the minimal TT-precedence edge 
outbound from v (min** (outbound (v))) are contained in the same segment; and 

• Each non-minimal TT-precedence outbound edge is at the head of a distinct segment. 

The concept of head and tail of each segment can be extended such that: 

• The head (tail) edge of a segment is the edge with the minimum (maximum) precedence 
within that segment: 

headEdge(s) = min(sn£);and 
tailEdgc (s) = max(sn£). 

• The head (tail) vertex of a segment is defined as the vertex the head (tail) edge is outbound 
from (inbound to): 

headVertex (s) = out (headEdge (s)); and 
t ail Vertex (s) = in (tailEdgc (s)). 

• For example, if the head edge is (u — > v) and the tail edge is (x — > y) then the head vertex 
is u and the tail vertex is y. 
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Given this definition then the following relationships can be defined between segments: 

Definition 4.1.3. The "is an ancestor of" relationship can be defined on the set of segments 
(§) such that segment s a is an ancestor of segment sp if, and only if, s a ^ sp and s a contains 
any element (vertex or edge) a and sp contains any element (3 such that a -< f3. 

The set of ancestors of a given segment is defined to be the maximal set of segments which are 
each an ancestor of that segment. 

Corollary 4.1.4. If s a is an ancestor of sp then there must exist elements a E s a and 



(3 € sp where a ~< /3. Given that segments are disjoint and maximal (with regards to set 
inclusion of -< related elements between its head and tail - definition 4.1.2) then head(s Q ) =^ 

a -< head (sp) =4 P therefore s a is an ancestor of sp if, and only if, head (s a ) -< head (sp). 



Corollary 4.1.5. The "is an ancestor of" relationship is anti-symmetric and transitive - 
this follows directly from the fact that the =^ relationship is a partial order (reflexive, anti- 
symmetric and transitive) relationship and that if s a is an ancestor of sp then: 

• s a ^ sp and so the "is an ancestor of" relationship is not reflexive; and 

• The elements at the head of s a and sp are related via -< so, it still holds from this 
relationship that, the '"is an ancestor of" relationship is anti-symmetric and transitive. 

For example, if segment s n has ancestors {si, S2, S3, . . . , s„_i} and is preceded by the 
chain [r; head (s„)[ which can be split into disjoint sub-chains such that [r; head (s 2 )[ C s 1; 
[head (s 2 ); head (S3) [ c S2, [head (S3); head (.84) [ C S3 ... and [head (s„_i); head (s„)[ C s n -i 
then si is an ancestor of s 2 which are ancestors of S3 which are ancestors of . . . which are 
ancestors of s„_i which are all ancestors of s„. 



Definition 4.1.6. The "is a descendant of" relationship is defined such that segment s a is 
a descendant of segment sp if, and only if, sp is an ancestor of s a . 

The set of descendants of a given segment is defined to be the maximal set of segments which 
are each a descendant of that segment. 

Definition 4.1.7. The "is a parent of" relationship is defined such that the parent of 
segment s is the ancestor of segment s where all other ancestors of s are also ancestors of 
that parent segment. 

• parent (s) = s p : s p € ancestors (s) , Vs a € ancestors (s) \ {s p } , s a € ancestors (s p ) 

Definition 4.1.8. The "is a child of" relationship is defined such that segment s a is a child 
of segment sp if, and ony if, sp is a parent of s a . 

The set of children of a given segment is defined to be the maximal set of segments which are 
each a child of that segment. 

• children (s) = {s c € descendants (s) : parent (s c ) = s} 

Definition 4.1.9. If two segments have the same parent then they are defined to be siblings. 

Definition 4.1.10. The segment containing the root vertex of the Tremaux Tree is defined 
to be the root segment and has the following properties: 

• No element of the Tremaux Tree precedes the root vertex so the root segment has no 
ancestors and, hence, has no parent so is not a descendant, child or sibling of any other 
segment. 

• The root vertex precedes all other elements of the Tremaux Tree so all other segments are 
descendants of the root segment; hence, each non-root segment has at least one ancestor 
(the root segment) and has a parent segment. 
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Considering the composition of segments: 

Definition 4.1.11. The leaves of the 
Tremaux Tree relative to any given element x 
are defined as the set of elements succeeding 
or equal to x with no successors (i.e. all cotree 
edges and vertices with no outbound edges): 

• leaves (x) = {y G V U (£\ J) : x 4 
y,{$zeVU£:y^z)} 

• V.t G V U £ : C leaves (a;) C leaves (r) 

• The leaves of a Tremaux Tree are 
defined as the maximal set of leaves for 
that Tremaux Tree - i.e. the leaves of 
the tree's root vertex (leaves (r)). 

Lemma 4.1.12. There is a bijection (one- 
to-one correspondence) from the set of leaves 
of the Tremaux Tree to the set of segments 
such that each leaf is the tail element of 
exactly one segment and the tail of each 
segment is a leaf. 

Proof 4.1.13. Given a segment containing 
a leaf element then that leaf and all other 
elements in the segment are related via -< (def. 

4.1.1) and since no element succeeds a leaf 
(def. 4.1.11) then every leaf element is the 
tail element of its containing segment and no 
segment can contain multiple leaves. 

If the tree edge (u v) is contained in a 
segment then so is vertex v (def. 4.1.2) and 
since u -< (u-^-v) -< v (def. 3.1.4) then no 
tree edge (u v) can be the tail of a segment. 

If a vertex u with outbound edges is contained 
in a segment then so is the edge (u — > v) with 
minimal TT-precedence of outbound (u) (def. 

4.1.2) and since u< (u-¥v) (def. 3.1.4) then 
no vertex with outbound edges can be the tail 
of the segment. 

Since no segment can have a tree edge or 
vertex with outbound edges as its tail then its 
tail must be either a cotree edge or a vertex 
with no outbound edges - these elements have 
no successors within, and are leaves of, the 
Tremaux Tree (def. 4.1.11). 

Since: each leaf of the Tremaux Tree is 
contained in exactly one segment (def. 4.1.2); 
each segment's tail is a leaf; and segments 
cannot contain multiple leaves; then there is a 
one-to-one correspondence between leaves and 
segments. □ 
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Figure 4.1.1: Nine segments (shown as coloured 
groups) which comprise the Tremaux Tree of 
Example Graph (Figure 3.1.1) 
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Definition 4.1.14. The set of segments 
can be partitioned into four distinct classes 
such that, given a segment s with tail edge 
(u — the classes can be defined by the 
precedence of the tail vertex v: 

Class 1: headVertex (s) -< (u-^-v) -< v 

(figure 4.1.2a); 
Class 2: headVertex (s) -< v -< (u-^-vJ 

(figure 4.1.2b); 
Class 3: v = headVertex (s) -< (u v) 

(figure 4.1.2c); or 
Class 4: v -i headVertex (s) -< (u-^v) 

(figure 4.1. 2d). 



Lemma 4.1.15. The head of each segment of a Tremaux Tree is: 

• The root vertex - for the root segment; 

• A tree edge - for non-root segments containing vertices; or 

• A cotree edge - for non-root segments containing no vertices. 

Proof 4.1.16. The root vertex r precedes all other vertices and edges within the Tremaux 
Tree (def. 3.1.1 and 3.1.4) and since the head of a segment is the element with minimal 
precedence then the root vertex is always at the head of the segment containing it. 

Each tree edge, (u-^vj € 3*, is inbound to a distinct non-root vertex, v € V, (corollary 3.1.3) 
and since (it-^>i>) -< v (def. 3.1.4) and that (u-^-vj and v are contained in the same segment 
(def. 4.1.2) then there is always a tree edge with lower precedence contained in the same 
segment as each non-root vertex; therefore no non-root vertex can be at the head of a segment. 

Cotree edges are leaves of the Tremaux Tree (def. 4.1.11) and are at the tail of their respective 
segments (lemma 4.1.12) so have the highest precedence within those segments. Therefore 
vertices or tree edges in a segment with a cotree edge must have lower precedence so a cotree 
edge cannot be at the head of a segment unless it is the only element in that segment. 

Given this, for any segment: if it contains the root vertex then that will be at the head of 
the segment; if the segment contains vertices, but not the root vertex, then it also contains 
a distinct tree edge for each non-root vertex and the minimum precedence element is the 
minimum precedence tree edge; otherwise, the segment contains no vertices and, hence, no tree 
edges and so only a single cotree edge which is head (and tail) of the segment. □ 

Corollary 4.1.17. For a non-root segment s then head (s) is an edge (u—> v). Since vertex 
u immediately precedes (u —¥ v) (def. 3.1.4) therefore u is contained in the maximum precedence 
ancestor segment of s - the parent segment of s. 
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Figure 4.1.2: Examples of Segment Classes 
Based on Tail Vertex Precedence (Head Vertex 
in Red) 
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Definition 4.1.18. A bridge edge is an edge of 3 not contained in any biconnected 
components of 3 (and, hence, is not contained in any cycles of 3)- 



Lemma 4.1.19. Each cotree edge is part of a cycle and, hence, a biconnected component. 



Proof 4.1.20. Each cotree edge (u-^k-v) has the relationship v =4 u -< (u-^k-v) (def. 
3.1.4) so the chain [v;u] and (u-^v) define a cycle; hence (u-^v) is part of a biconnected 
component. □ 



Corollary 4.1.21. All bridge edges are tree edges. 



Lemma 4.1.22. A given tree edge (u A v) is a bridge edge if, and only if, lowPointl (v) 



v. 



Proof 4.1.23. Given that lowPoints (v) C [r;v] (def. 3.1.8) and that no vertex succeeds u 
and also precedes v (def. 3.1.4) then either lowPointl (v) = v or lowPointl (v) =4 u. 

If lowPointl (v) =4 u then, for that low point to be reachable, a cotree edge (x lowPointl (u)) 
exists such that lowPointl (v) =4 u -< (u^-v) -< v =4 x -< {x lowPointl (v)) . Given this then 
the chain [lowPointl (v); (x lowPointl (w))] defines a cycle and contains (u^->v); therefore 
if lowPointl (v) =4 u then (u A v) is contained in a cycle and is not a bridge edge. 

If lowPointl (v) = v then all edges reachable from v (succeeding v) are inbound to and 
outbound from vertices succeeding or equalling v so no edges reachable from v connect to 
u or its predecessors; given this then (u^s-w) cannot be contained in a cycle and is a bridge 
edge. 

Therefore (u^>w) is a bridge edge if, and only if, lowPointl (v) = v. □ 



Corollary 4.1.24. Given a tree edge (u v) where vertex v has no outbound edges then 
reachable (v) = {v} = lowPoints (v ) therefore lowPointl (v) = v so (u v) is a bridge edge. 

Lemma 4.1.25. All edges which are contained in the same segment as, and precede, a bridge 
edge are also bridge edges. 



Proof 4.1.26. 

[1] (v ^> w) is a bridge edge lowPointl (w) = w (lemma 4.1.22) 

lowPointl ((v^-w)) =v (def. 3.1.8) 

[2] (u ^> w) and (v ^> w) are in the same segment 

(v Aw) = min** (outbound (v)) (def. 4.1.2) 

=> Ve G outbound (w) : lowPointl ((w A w)) =^ lowPointl (e) 
[1] and [2] Ve G outbound (u) : lowPointl (e) = v 

=>■ lowPointl (u) = u 

=> (u-^-w) is a bridge edge (lemma 4.1.22) 

Therefore, if tree edge (w w) is a bridge edge and an immediately preceding tree edge (u u) 
is contained in the same segment then it will also be a bridge edge. Applying this recursively 
to each preceding (tree) edge then all edges contained in the same segment as, and preceding, 
a given bridge edge are also bridge edges. □ 



Corollary 4.1.27. If a segment's tail is a vertex (with no outbound edges) then, given 
lemma 4.1.25 and corollary 4.1.24, all edges in that segment are bridge edges. 
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Lemma 4.1.28. Considering the tail vertex of a given segment then: 

• All elements within that segment that equal or succeed its tail vertex have identical first 
low points; and 

• All edges within that segment that precede its tail vertex are bridge edges and those bridge 
edges each have different first low points equal to the vertex immediately preceding that 
bridge edge. 



Proof 4.1.29. Given a segment containing vertex v and, hence, also containing the 
immediately preceding tree edge (u^>u) (def. 4.1.2) then, considering the first low point 
of vertex v, either: 

• lowPointl (v) =4 u, in which case: 

— (u v) is not a bridge edge (lemma 4.1.22); 

— The minimum reachable vertex from (u v) is either vertex u or the minimum 
reachable vertex from vertex v and since this precedes or equals u then 
lowPointl ((w u)) = lowPointl (v); 

— Therefore each non-bridge tree edge has the same first low point as the immediately 
succeeding vertex within the same segment; or 

• lowPointl (v ) = v, in which case: 

— (u v ) is a bridge edge (lemma 4.1.22); 

— All other preceding edges in that segment are also bridge edges (lemma 4.1.25); 

— For each bridge edge (w-^>v), since lowPointl (v) = v, then lowPointl ((u-^>v)) = 
u 7^ lowPointl (v); 

— Therefore each bridge edge has a first low point equal to the immediately preceding 
vertex and different to the immediately succeeding vertex so all bridge edges within 
a segment have different first low points. 

Considering a segment such that edge (x — > y) and the immediately preceding vertex x are 
both contained in that segment then: lowPointl ((x — >yj) =4 x (def. 3.1.8); and since (x^y) 
has the minimum TT precedence of all edges outbound from x (def. 4.1.2) then its first low 
point precedes or equals the first low point of all other edges outbound from x therefore, 
lowPointl (x) = lowPointl ((x^y)) =4 x. 

Given the above statements, considering a segment containing the elements (u^>w), v and 
(v — > w) then: 

• If lowPointl ((v — > w)) =4 u then lowPointl ((u v)) = lowPointl (v) = 
lowPointl ({v — > w)); and 

• If lowPointl ((v— >w)) = v then (u ^> v) is a bridge edge, lowPointl ((u^>w)) = u and 
lowPointl (v) = lowPointl ((v — > w j) = v. 

Considering a segment s then either: 

• The segment's tail is a vertex v with no outbound edges (fig. 4.1.2a). In which case, all 
edges in that segment are bridge edges (each with different first low points) and v is the 
only element equalling or succeeding the tail vertex (which is also v); 

• The segment's tail is a cotree edge (u-^-v) where v =4 head(s) (fig. 4.1.2c or d) then, by 
recursively applying the above statement, the segment contains no bridge edges and all 
elements have identical first low points; or 

• The segment's tail is a cotree edge (u-^v) where head (s) -< v (fig. 4.1.2b) then: 

— By recursively applying the above statement, the elements within that segment 
succeeding or equal to v all have a first low point equal to v; and 

— Given that head (s) -< v there must exist a tree edge (x ^> v) immediately preceding 
v and since lowPointl (v) = v then (x-^-v) is a bridge edge (and so are all other 
preceding edges within s). 



Therefore, in all cases the lemma is true. 



□ 
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4.1.1 Ordering the Segments 



Definition 4.1.30. A total order (< s ) can 
be defined on the set of segments such that 

s a < s sp if: 

• s a is an ancestor of sp; 

• s a is a sibling of sp and 
headVertex (sp) -< headVertex (s a ); 

• s a is a sibling of sp, headVertex (s a ) = 
headVertex (s^) and head(s Q ) <** 
head (sp); or 

• s Q is a descendant of or equal to s' a and 
S/3 is a descendant of or equal to s'p such 
that s' a is a sibling of s'p and < 8 s'p. 

Example 4.1.31. Given the segments from 
figure 4.1.1 then [A; (L A)] is the root 
segment and the other segments descend from 
it as described in figure 4.1.4 (below) and are 
in < s precedence order as numbered in figure 
4.1.3 (right). 




Figure 4.1.3: Segments from Figure 4.1.1 
Numbered in < s Order 
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Figure 4.1.4: Segment Parent-Child Relationships from Figure 4.1.1 



Corollary 4.1.32. Considering definition 4.1.30 and the precedence of the head vertices 
and head edges of related segments then: 

• If segment Sj is a descendant of segment then < s Sj and headVertex (sj) -< m 
headEdge (s^) ~< headVertex (sj) -< m headEdge (sj); 

• If segment is a sibling of segment Sj where S{ < s Sj then headVertex (sj) =4 
headVertex (sj) and headEdge (sj) headEdge (sj) (since Sj and Sj are in different 
branches of the Tremaux Tree) ; 

• If segment Sj is a descendant of a sibling segment Si of segment Sk where 
Si < s st then s< < s Sj < s Sfe and headVertex (sfc) headVertex (sj) -<!,„ 
headEdge (si) -< headVertex (sj ) -<„, headEdge (sj) and headEdge (sj) / headEdge (sk) 
and headEdge (s^) / headEdge (s^). 
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4.1.2 Varying the Order of Incomparable TT-Precedence Edges 

Definition 3.1.13 defines a total order (<** ) over each vertex's set of outbound edges by assigning 
an arbitrary order to those edges which have an incomparable TT-precedence (||* ). Considering 
a set of ||* edges outbound from a given vertex v which is contained in a segment s then any 
given edge will be either: 

• The minimal <** edge - in which case, it will be contained in s. Varying the arbitrary 
order assigned to that set of ||* edges such that a different edge has minimal precedence 
results in a different chain of elements within s, succeeding v but having identical tail 
vertex (since all ||* edges have the same first low point). 

• A non- minimal <** edge - in which case, all these edges will be at the head of segments 
which are siblings and are children of s. By definition 4.1.30, the <** propagates through 
to the < s order for a segment's children; by varying the arbitrary ||* order then the < s 
order varies and, importantly, vice versa. When considering a subset of the total order 
< s corresponding to the set of children of a given segment, an additional point to note, is 
that child segments with |j* head edges will, by definition 4.1.30, be sequentially ordered 
within this subset of children. 

The impact of varying the order of the segments, in the context of a planar embedding, is 
considered in the following section. 
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4.2 Planar Embedding 

This section deals with a planar embedding T of a graph S ("V, £) onto a surface M (which is 
assumed, in this and future references, to be orientable and of genus 0; i.e. the IR 2 plane or the 
surface of a sphere). It considers the incremental addition of segments, in < s precedence order, 
to the embedding such that each successive segment has either: 

• A planar embedding directly within the embedding of lower < s precedence segments; 

• A planar embedding within the embedding of lower < s precedence segments after they 
have been re-oriented via one or more Whitney flips; or 

• No possible planar embedding even after considering re-orientation of previously embedded 
segments via Whitney flips, so the graph is non-planar. 

In addition, the case is considered where all segments are embedded and re-orientation of the 
segments is still possible thus allowing for multiple embeddings of the same graph. 

Definition 4.2.1. A graph is defined to be planar in the following, equivalent, conditions: 

• It has a planar embedding (a topological representation without edge crossings on an 
orientable surface of genus - i.e. the surface of a sphere or the W 2 plane); 

• It does not contain a sub-graph homeomorphic to K 5 or K 3 ^ [44]; 

• It does not contain K 5 or a if 3j3 as a minor [78]; 

• It has a dual [81]; and 

• The Tremaux Tree of the graph does not contain a pair of cotree edges which are defined 
to be both T-opposite and T-alike [18]. 



4.2.1 Embeddings, Faces and Regions 

Definition 4.2.2. An embedding is a mapping of a graph S (V, £) onto a surface M such 
that each vertex maps to a point on M and each edge maps to an open curve (or closed curve 
for a looping edge) on M terminating at the points corresponding to the incident vertices. A 
planar embedding V is such that each vertex maps to a distinct point on M and each edge is 
a Jordan arc (or, for looping edges, a Jordan curve), which does not intersect with any points 
mapping to other edges or vertices except at its incident vertices. 

Given a sequence of segments (si . . . s u ) (in < s order) then a sequence of sub-graphs (S • • • Sw) 
can be formed, where S„ = Ui<fe<„ s k- If S w is planar then each sub-graph is also planar and 
there exists a corresponding sequence (r . . . T w ) of planar embeddings of those sub-graphs on 
the surface M. The following terminology is used relating to those embeddings: 

Definition 4.2.3. A face of T„ is a maximal set of connected points within the complement 
M\T„. A vertex/edge is defined to be adjacent to face (and vice versa) if that vertex/edge is 
contained in the boundary of that face; similarly, a face is adjacent to a segment if a vertex or 
edge contained in that segment is adjacent to that face. Thus, a face of T n may, in Y x (where 
n < x), contain the embedding of segment s x and so have been sub-divided and not exist in 
that later embedding; this means that the number of faces adjacent to a vertex/segment can 
increase with successive embeddings. 

Definition 4.2.4. A region relative to segment s n is defined to be a face of T n adjacent to 
s n at the instant of its embedding. 

Corollary 4.2.5. Given that each segment s n is a chain of connected elements then a 
planar embedding of s n must be entirely within a face / of r(„_!) and so the region(s) relative 
to s n correspond to the face(s) formed by the subdivision of / by s n and all elements of s n are, 
at that instant, only adjacent to those face(s) composing the region(s) relative to that segment. 

Faces are subdivided by subsequent embeddings and change with those sub-divisions, however, 
regions are constant areas and are comprised of one or more faces and zero or more (descendant) 
segments and can contain nested regions corresponding to the segment hierarchy. 
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Lemma 4.2.6. If a graph has a planar embedding on the surface of a sphere then there is a 
corresponding planar embedding on the M 2 plane, and vice versa. 



Proof 4.2.7. The surface of a sphere can 
be mapped, using a stereographic projection 1 
(figure 4.2.1), onto a M 2 plane; thus by 
choosing a point, on the surface of the 
sphere, within a face of the embedding as 
the focal point of the projection then a 
stereographic projection maps the embedding 
to a corresponding embedding in the plane. 
The inverse projection maps an embedding in 
the ]R 2 plane onto the surface of a sphere. □ 

The implication of Lemma 4.2.6 is that 
a graph's embedding can be, equivalently, 
considered on the surface of a sphere and in 
the R 2 plane. 

4.2.2 Segment Classes 

Recalling definition 4.1.14, this details four 
classes of segment (examples of which are given 
in figure 4.2.2) based on precedence of the tail 
vertex. 

Notation 4.2.8. Defining a shorthand no- 
tation for the head, tail and low points of a 



z. Zenith 



segment 


°x • 


• v h 


= headVertex (s x ), 


• v t 


= tailVertex (s x ), 


• e l 


= headEdge (s x ), 


• ef 


= tailEdge^), 




= lowPointl (e?) and 


• v h 


= lowPoint2 (e%). 




Figure 4.2.1: Stereographic Projection 
Mapping Between the Surface of a Unit 
Sphere (P = (1, A, <p)) and the M 2 Plane 

(Q=(cot(A/ 2 ),^)) 2 
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Using this, a segment s x of a given Class has 
the following relationships between elements: 



Figure 4.2.2: Examples of Segment Classes 
Based on Tail Vertex Precedence (Head 
Vertex in Red) 



Class 
Class 
Class 
Class 



= VT = VI 



=4 e 



-<m 1 

-< e? 



= vf -< v, =s! v\ 



-<n 



e\ =^ ef; and 



1 The R 2 reference plane can be described using polar co-ordinates Q = (r,8), relative to the origin O. The 
surface of a unit sphere can be described using spherical co-ordinates P = (1, A, ip) where for given zenith (normal 
to the reference plane) and azimuth (within the reference plane) reference directions, emanating from the origin 
O, then: 

• The intersection of the unit sphere and the zenith reference direction is at Z = (1,0, <p z ) where ip s is 
arbitrary but, by convention, can be denned to be 0; 

• ip is the azimuth angle (the angle [0; 2tt[ between the azimuth reference direction and the orthogonal 
projection of the line OP onto the reference plane); 

• A is the zenith angle (the angle ]0;7r] between the zenith reference direction and OP). 

A stereographic projection, using Z as the projection's focal point, maps P to Q where Q is the point of 
intersection of the reference plane and line through ZP (such that 8 = ip and r = cot (V 2 ))- 

2 WT^K. PGF/Tikz Stereographic Projection code adapted from Tomek M. Trzeciak's code from 
http : //www . latex- community . org/f orum/viewt opic .php?f=4&t=2 11 l&p=8260 
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4.2.3 Defining Segments As "Having An Embedding" 

Each segment is: a simple path (Class 1 or 4); a simple cycle (Class 3); or a simple cycle with 
a branching path connected at a single vertex (Class 2) - so, when considered independently, 
each has a planar embedding within a surface. Given this then the construction of a planar 
embedding can be considered such that: 

• The root segment si always has a planar embedding Ti within an empty surface T ; and 

• Each subsequent segment Sk has a planar embedding Tk within the planar embedding T^-i 
of all previously embedded segments {s\, S2, ■ ■ ■ Sfc-i} (all having lower < s precedence than 
Sk) if, and only if, there exists a face of T k _i whose boundary contains all vertices incident 
to that segment (i.e. its head vertex and, for a Class 4 segment, its tail vertex) and, hence, 
that segment can be embedded without crossing the boundary to that face. 

To prevent a segment being considered for embedding in a face that cannot contain an embedding 
of that segment's descendants then this definition is further restricted such that: 

Definition 4.2.9. A non-root segment s x is defined as having an embedding if, within a 
planar embedding of the sub-graph formed exclusively of all lower < s precedence segments, 

there exists a face / with cycle 6/ of boundary vertices where ({t^} U [?;f 2 ;^]) C 6/. 

. . 

Corollary 4.2.10. Any face that can contain an embedding of a segment contains all 
low points of that segment on its boundary; this follows directly from definition 4.2.9, since 
lowPoints (e£) C ({w^} U [vf 2 ;^])- Therefore, all vertices at which a segment's descendants 
connect to an ancestor of that segment are also contained on the boundary of the face containing 
the embedding of that segment. 

Corollary 4.2.11. As a corollary to this and definition 4.2.4, each segment's embedding is 
either a simple path (Class 1) or defines a cycle, either of itself (Class 2 or 3) or with ancestors 
(Class 4). By Euler's formula [22] and the Jordan Curve Theorem [39] then: the embedding 
of a Class 1 segment defines one adjacent region; and the embedding of a Class 2, 3 or 4 
segment defines two adjacent regions which can be designated as the "inside" and "outside" 
regions relative to that segment. 



Considering this further: 



Theorem 4.2.12. If the biconnected components of a graph 9 are planar, 9 is planar. 




Proof 4.2.13. This is proved by Whitney [81, Pg. 356]: "Suppose the graphs 9i and S2 are 
planar, and 9' is formed by letting the vertices ai and 02 of 9i and 92 [respectively] coalesce. 
[. . .] Map 9i on a sphere, and map 92 on a plane so that one of the regions adjacent to the 
vertex a 2 is the outside region. Shrink the portion of the plane containing S 2 so it W M fit into 
one of the regions o/9i adjacent to a\. Drawing 01 and a 2 together, we have mapped 9' on the 
sphere. The theorem follows as a repeated application of this process." □ 

Corollary 4.2.14. Since each non-root Class 1, 2 and 3 segment defines a 1-separation 
at its head vertex 3 (separating that segment and its descendants from its ancestors and those 
ancestors other descendants) then appending a Class 1 , 2 or 3 segment within a face of planar 
embedding always results in a planar embedding. 



Corollary 4.2.15. Following corollary 4.2.14, a planar embedding of a graph can be 
constructed segment-by-segment (in ascending < s order) if, and only if, each Class 4 segment 
has a planar embedding within a face of the (respective biconnected component of the) sub- 
graph formed by all lower < s segments. 



3 And, given that lowPoints (head (s^)) = {headVertex (s;)} when Si is of Class 1, 2 or 3, then this property is 
maintained as subsequent segments are appended to the embedding. 
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4.2.4 Defining Sides to the Root Segment 



When considering the embedding of the root segment in the R 2 plane, convention describes 
the "inside" ("outside") of a Jordan curve to be the finite (infinite) bounded adjacent faces; 
mapping this embedding to a sphere (via stereographic projection) then rotating (or mirroring) 
to swap the northern and southern hemispheres before mapping back to the R 2 plane results in 
reversal of the "inside" and "outside" faces and the natural affordance between the R 2 surface 
and the designation of these faces is lost. Therefore, it is useful to designate a segment's adjacent 
faces/sides as "inside" or "outside" independent of any presumptions of the (orientable genus 0) 
surface being used for the embedding; this can be achieved by attaching a child segment to one 
side of the root and defining that side to be the "inside" and the other side to be the "outside". 



\~ O 



(a) Class 
1 Root 
with 
Class 1 
Child 





(b) Class 
1 Root 
with 
Class 2 
Child 



(c) Class 
1 Root 
with 
Class 3 
Child 



(d) Class 
2 Root 
with No 
Child 



(e) Class 
3 Root 
with Class 
1 Child 



(f) Class 
3 Root 
with Class 
2 Child 



(g) Class 
3 Root 
with Class 
3 Child 



(h) Class 

3 Root 
with Class 

4 Child 



Figure 4.2.3: Inside (Yellow) and Outside (Brown) Adjacent Regions of Different Classes of 
Root Segment (Black/Blue) as Defined by Location of Branching Path/Cycle 



Figure 4.2.3 shows minimal examples of the possible classes or root segment and children (if 
any) that are required to define the sides adjacent to the root segment. 

• A Class 1 root segment (figures 4.2.3a-c) requires a child segment to define a side. One 
can consider extending the path defined by a Class 1 root segment to form a cycle (for 
example: by including the root segment as part of the boundary of a cycle with infinite 
radius in the M 2 plane; or as a section of a great circle on the surface of a sphere) to 
separate the surface into two regions - positioning the child segment within one of these 
regions defines that region to be the "inside" and the opposing region as the "outside". 

• A Class 2 root segment (figure 4.2.3d) requires no child segment as the side of the cycle 
containing the leading path of bridge edges can be defined to be the "inside" and the 
opposite side of the cycle as the "outside". 

• A Class 3 root segment (figures 4.2.3e-h) requires a child segment to define a side such 
that the side of the root segment containing that child is defined as the "inside" and the 
opposite side of the cycle as the "outside". 

This leads to the definition of a static segment: 

Definition 4.2.16. The root segment is defined to have a static embedding (or, simply, to 
be static) such that the root segment defines a cycle (either of itself, for a Class 2 or 3 root 
segment, or by extension, for a Class 1 root segment) and that the cyclic orientation of the root 
segment's edges about that cycle is in a static direction. A branching path/cycle (a leading 
path of bridge edges, for a Class 2 segment, or by the root segment's child with minimal < s 
precedence, for a Class 1 or 3 segment) within one region bounded by that cycle defines that 
region to be the inside and the opposing region to be the outside. 

This is static since, regardless transformations to the embedding of subsequent segments, the 
root segment's cyclic direction and the branching path/cycle's containing region is unchanged 4 . 

Corollary 4.2.17. Since no sub-graph formed by the root segment and any static 
branching path/cycle is homeomorphic to either a or a -^"3,3 then the static segment(s) 
must have a planar embedding. 



4 Although the cyclic direction of a branching cycle can be changed within that region 
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4.2.5 Defining the Inside and Outside Relative to Non-Root Segments 

Considering the non-root segments then it is useful to extend the definition of "inside" and 
"outside" used for the root segment: 

Definition 4.2.18. Given a planar embedding T x of a segment s x which forms a cycle, 
either of itself (Class 2 or 3) or with its ancestors (Class 4), within a face / (with boundary C/) 
of the embedding T x _i then, by the Jordan Curve Theorem (see page 9), the segment bisects 
/ forming two regions/faces adjacent to, and separated by, that segment. These regions can 
be designated as inside and outside of s x such that: 

• If s x is a Class 2 or 3 segment then the inside region is bounded by the cyclic chain [vf; ef] 
and the outside region is bounded by (Qf U s x ); and 

• If s x is a Class 4 segment then 6 is a Jordan curve and can be partitioned, at vf and 
vf, to form two Jordan arcs Ci and C 2 where: C 2 = (e/\Ei) U {vf,vf}; and Ci (C 2 ) 
is defined to be the arc containing the edge immediately preceding/inbound to (not 
preceding/outbound from) vf. Given these definitions then the inside region is defined to 
be the face bounded by (Ci U s x ) and the outside region is defined to be the face bounded 
by (C a U s x ). 

Corollary 4.2.19. For a Class 4 segment s x to have an embedding within face /, then 6/ 
contains vf and the chain [vf ; vf] (definition 4.2.9). Given this (and that vf -< vf so there is 
always an edge immediately preceding vf), then considering the regions formed: 

• The inside region contains the immediately preceding edge to vf within C/, so is bounded 
(in part) by the path ([vf ;vf\ U s x U (vf)); and 

• The outside region contains the immediately succeeding edge to vf within 6/, so is 
bounded (in part) by the path ((vf) U s x U (vf)) and the chain [vf ; vf [ does not bound 
the outside region. 

Figure 4.2.4, below, gives examples of the inside and outside regions formed when a cyclic 
segment is embedded within a face. Figure 4.2.4a is an example of the embedding of a Class 2 
segment; figure 4.2.4b is a similar example for a Class 4 segment; and figure 4.2.4c extends figure 
4.2.4b by embedding an additional Class 4 segment within the previously generated outside face. 




(a) Class 2 Segment s 
embedded within face 
bounded by cycle C 
with inside bounded 
by [ii; rie wj and 
outside bounded by 

(eus) 




(b) Class 4 Segment 
s a embedded within 
face bounded by cycle 
(Ci U 62) with inside 
bounded by (Ci U s a ) 
and outside bounded 
by (C 2 Us ) 




(c) Class 4 Segment 
sp embedded within 
outside face from (b) 
bounded by cycle 
(Ci U G 2 ) with inside 
bounded by (Ci U sp) 
and outside bounded 
by (e 2 Usp) 




(d) Example of the 
Degenerate Case 



Figure 4.2.4: Examples of Inside (Yellow) and Outside (Brown) Regions Formed by 
Embedding Different Segment Classes 



A degenerate case (figure 4.2.4d - red embedding) exists when the boundary of the (brown) face 
contains two edges immediately succeeding and no edge immediately preceding the head vertex. 
This case occurs when two segments have |j* precedence head edges (where both segments have 
a common head and second low point vertex) and is considered in more depth on pages 51 & 
68; however, the < s embedding order ensures there is always an embedding (green) in a (yellow) 
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face containing edges that immediately precede and succeed the head vertex so the segment can 
be embedded into that face and by carefully permuting the order the segments are embedded 
(which, in this situation, is permissible since the < s order of this pair of segments is based 
on an arbitrary ordering of the ||* head edges) then the degenerate case can be formed whilst 
maintaining the property that a segment is always embedded within a face containing an edge 
inbound to that segment's head. 



4.2.6 Embedding Class 1, 2 or 3 Segments 



Considering definition 4.2.9, we recall that given the embedding of a segment s x into a face / 
(which is bounded by the cycle of vertices C/) then lowPoints (e^) C Gf. 

If s x is a class 1, 2 or 3 segment then it connects to C/ at a single vertex (its head vertex) and, 
by corollary 4.2.15, always has a planar embedding. Given that any face containing that head 
vertex can contain that embedding then this can be further expanded such that a Class 1, 2 or 
3 segment always has an embedding within any face adjacent to its head vertex (figure 4.2.5) 
and as such: 



Definition 4.2.20. All non-static Class 1, 2 or 3 segments are defined to be rotatable (in 
that the embedding of that segment can be rotated around its head vertex and contained within 
any adjacent face). 

Further to this, each Class 2 or 3 segment defines a cycle and that cycle can be embedded such 
that the edges bounding that cycle have either a clockwise or anti-clockwise direction about the 
inside face of the embedding (figure 4.2.6). The root segment is fixed to have a static cyclic 
embedding direction but all other Class 2 or 3 segments can have the cyclic direction of their 
embedding reversed and as such: 

Definition 4.2.21. All non-root Class 2 or 3 segments are defined to be reversible (in 
that the cyclic direction of its edges, around the inside face defined by its embedding, can be 
reversed) . 





(a) Clockwise 



Figure 4.2.5: Example of Possible 
Embeddings of (Red) Segment Rotating 
About Head Vertex Into Different 
Adjacent Faces 



(b) Anti-Clockwise 



Figure 4.2.6: Example Clockwise 
Embedding of Class 2 Segment s and 
Reverse Anti-Clockwise Embedding 
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4.2.7 Embedding Class 4 Segments 

Each non-root segment connects to its head vertex which, by definition, is contained in its parent 
segment. That parent's embedding forms either: one adjacent face, if the parent is of Class 1; 
or, by the Jordan Curve Theorem, two adjacent faces (inside and outside) separated by that 
parent segment, if that parent is of Class 2, 3 or 4. Given this then, if a non-root segment has 
a planar embedding it must be within a face adjacent to its parent or a sub-division thereof 
formed by previously embedding sibling segments, or sibling's descendant segments (with lower 
< s precedence). 

Lemma 4.2.22. Given a segment currently being embedded then all of its previously 
embedded siblings and their descendants will have head vertices succeed or equal the head 
vertex of that given segment. 

Proof 4.2.23. Given the segments s x , s y and s z where s x < s s z such that s x and s z are 
siblings then, by the < s ordering, vf t =4 v%; if s y is a descendant of s x then, by the < s ordering, 
s x < s s y < s s z so, by the parent-child relationship, v% ~< v v h and hence =4 v% ~< v v h . □ 



Considering sequence (si, s 2 , . . . , s n ) of segments in ascending < s precedence order then a Class 

4 segment Sk (where v k ~< v k ) can be considered in the following cases: 

1. When Sk has no siblings with lower < s precedence and, hence, Sk-i is the parent of Sk 
and 1 -< v h' or 

2. When Sk-i is a sibling, or a sibling's descendant, of Sk and, hence, v\ 4 v* -1 , which can 
be considered in the following sub-cases: 

(a) v^v^vf-Uvt 1 ; 

(b) v k ^v^ 1 <v k <v k h ~\ov^ 

(c) v?- 1 4 v k <v k h ^ vf-\ which can be separated into the further sub-cases: 

i. vt 1 4 4 <v\< v k h ~\ 

ii. v k t 1 =v k <v k h = v k h 1 ; or 

iii. v*- 1 -< v k 4v k 4 v k h ~\ 

Embedding a Class 4 Segment onto its Parent without Siblings 

Considering case 1 then the parent Sfc_i cannot be of Class 1 and so its embedding forms a 
cycle, either of itself (Class 2 or 3) or with ancestors (Class 4), defining an inside and an outside 
adjacent region. Considering the Class of the parent then it must either be: 

• A Class 2 or 3 segment, which defines a cycle [i^ -1 ; e^" 1 ] onto which Sk is connected. 
By the definitions of the segment classes and from the parent-child relationship, then 
v?- 1 4 vt 1 4 < = v k <v k < et 1 hence lowPoints (e k ) C [v k ;v k ] C [t^ 1 ; e*" 1 ] 
so all low point vertices of Sfe are contained within the cycle defined by the parent Sk-i\ 
therefore, for a Class 2 or 3 parent segment: 

— Sfe always has an embedding within either the inside and the outside face adjacent 
to Sk-i (provided is not otherwise restricted by being defined to have a static 
embedding); and 

— There is always a pair of edges on that cycle which immediately precedes and 
immediately succeeds vfc (since v k -< v\ -t, e^ 1 ). 

5 If v£ -< v t -1 -< vfc = v h _1 then < s s^-i but since s^-i < s Sfe then this case cannot occur. 
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• A Class 4 segment, previously embedded into a face containing Sk-i's low points 
(lowPoints (e^ -1 )) on its boundary. The inside and outside faces defined by the embedding 
of s fc _i are bounded, in part, by the paths U s fe _i U (v^ 1 )) and ({v^' 1 ) U 

Sk-i U (v^ 1 )), respectively (corollary 4.2.19). 

If a vertex is reachable (definition 3.1.7) from e\ and given that e* _1 -< e\ then that vertex 
is also reachable from 1 therefore lowPoints (e*) C (lowPoints (e^ _1 ) U 
Therefore, for a Class 4 parent segment: 

— Sfe can always be embedded within the inside face relative to its parent; 

— If either v^ 1 v\ or (uf" 1 = v\) A (u^ -1 vf ) then can also be embedded 
within the outside face relative to its parent (provided Sk is not otherwise restricted 
by being defined to have a static embedding); and 

— There is always a pair of edges on the path formed by Sk-i which immediately 
precedes and immediately succeeds v\ (since v h ~* -< v\ < ef _1 ). 

This results in: 

Theorem 4.2.24. Any Class 4 segment s c can always be embedded within the inside face 
defined by the embedding of its parent s p . 

Proof 4.2.25. Contained in the paragraphs above. Dj 

Theorem 4.2.26. Any Class 4 segment s c can be embedded within the outside face defined 
by the embedding of its parent s p if, and only if, v v h =<I v% or (vf = vf) A (v% =^ vf 2 ) (or, 
equivalently, if s c has no low point vertices that are not on the boundary of the outside face 
defined by its parent - which will be any low point vertices that precede that parent's head 
vertex and succeed that parent's tail vertex) and that s c is not restricted from being embedded 
in the outside face by being defined to have a static embedding. 

Proof 4.2.27. Contained in the paragraphs above. □ 

Corollary 4.2.28. If the parent s p is of Class 2 or 3 then v v h v\ and, hence, no low point 
vertex v of a child s c can exist such that v\ ~< v -< v v h so all children of a Class 2 or 3 segment 
can always be embedded within both the inside and outside face defined by the embedding of 
s p (providing s c is not static). 



Theorems 4.2.24 and 4.2.26 both lead to the definition that: 

Definition 4.2.29. A Class 4 segment s is defined to be flippable if s can be embedded 
within both the inside and the outside relative to its parent when those regions are considered 
devoid of any sub-divisions due to previously embedded siblings or sibling's descendants. 



This terminology is used as it represents the fact that a flippable segment s c represents the 
potential existence of a Whitney flip, such that: 

• Considering s c 's parent (s p ) and the boundaries of the inside (C/) and outside (Co) regions 
adjacent to s p then if s c is flippable then the low points of s c (including its head and, if 
Class 3 or 4, tail vertices) must be contained in both 6/ and Co- 6/ H Co = {Vh,vf} U s c 
therefore if s c is flippable then lowPoints (s c ) £ ({v^, vf} U s p ). 

• If s c is embeddable within a region adjacent to s p then it is also embeddable within 
the region containing s p adjacent to each ancestor of s p since the regions adjacent to s p 
are recursively nested within regions adjacent to each successive ancestor; therefore, no 
ancestor if s p influences the embedding of s c . 

• A similar determination can be made for segments which are unrelated to s p by noting that 
the head of those unrelated segments cannot be contained in the boundary 6/ and since 
s p has a valid embedding then no other vertex contained in, or incident to, any unrelated 
segment can be incident to s c and either adjacent to the outside region relative to s p or is 
not contained in any region relative to s p so has no bearing on the embedding of s c . 
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• By the definition of low points (3.1.8) then any child of s c will have low points contained 
in (lowPoints (s c ) U s c ) and so is also contained in either Cj fl Co or s c and does not restrict 
s c from being embedded in either region. This point can be applied recursively to consider 
all descendants of s c and thus if s c is flippable then no descendant of s c influences this 
(beyond the consideration of s c 's low points). 

• Since all other segments are accounted for then the only segments which can impact 
whether s c can be embedded in both regions adjacent to its parent are s c 's siblings and their 
descendants. Since these are specifically discounted by the definition of a segment being 
flippable then the flippable nature of a segment can be solely determined by comparing the 
precedence of v\ and vf to and (such that if s c is flippable then either v v h =<; vf or 
(vf = vf i Av p h ^vf i ). 

Thus if s c is flippable then, unless restricted by a sibling or sibling's descendant, there exists a 
Whitney flip of the cycle defined by s c and its parent. If a segment is not flippable then it is 
immediately restricted from being in the outside face so has a fixed embedding within the inside 
face (and a 3-separable minor exists formed from that segment and sufficient ancestors) . 

Embedding a Class 4 Segment onto its Parent with Siblings 

Considering Case 2 (from page 46). Substituting Sj for Sk-i and assuming that Sj and Sk are 
within the same face adjacent to their common ancestor Sj, then the sub-cases take the forms 
shown in figure 4.2.7. 




(a) Case 2a (b) Case 2b (c) Case 2(c)i (d) Case 2(c)ii (e) Case 



Figure 4.2.7: Embeddings of Segments Si, Sj & Sk Where Si < s Sj < s Sk and s; is the Parent 
of Sfc and is an Ancestor of Sj (Sub-Cases of Case 2, Pg. 46) and Showing Inside (Yellow) and 
Outside(Brown) Faces Defined by Sj. 

Partially and Fully Embedding Segments 

Considering Case 2a (figure 4.2.7a) where v% =4 vf so Sk is contained within the outside face 
relative to Sj (and conversely, if Sk has an embedding then Sj is on the boundary of the outside 
face relative to s^): 

Theorem 4.2.30. Given segments Sj and Sk where Sj < s Sk and v\ =^ vf then no segment 
with higher < s precedence that Sk connects to a vertex with higher precedence than vf . 
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Proof 4.2.31. A segment s x with higher < s precedence that s k is (by definition 4.1.30) 
either: 

• A descendant of s k ; 

• A sibling of s k where v% =4 v^; 

• A descendant of a sibling of s k where that sibling's head vertex precedes or equals v\; 

• A sibling of an ancestor of s k where v% =4 v h or 

• A descendant of a sibling of an ancestor of s k where that sibling's head vertex precedes 
or equals that ancestor's head vertex which precedes v\. 



Letting P be 



the path from the root vertex containing Sj. 



If s x is a sibling of s k with higher < s precedence than s/~ then (by definition 4.1.30) v% =4 v%. 
Since each edge connects two comparable (_L) precedence vertices (definition 3.1.1) and s x 
branches at from P then no vertex on P succeeding v% is reachable from any element of s x . 

Similarly, if s x is a sibling of an ancestor segment s a of s k where s k < s s x then v% =4 v% -< v\ 
and s x branches from P at v% so no vertex on P succeeding v% is reachable from any element 
of s x . 

Considering the cases when s x is a descendant of, or a descendant of a sibling of, or a descendant 
of a sibling of an ancestor of, s k then in all cases s x is a descendant of a segment which branches 
from P and since the head vertex of that branching segment has the highest precedence of 
vertices on P that is reachable from any element of that branching segment then, by definitions 
3.1.1 & 3.1.7, it follows that no descendant of that branching segment can reach a higher 
precedence vertex. Given that =4 ^ an d that the branching segments are either s k , a 
sibling with a head vertex preceding or equalling s k or an ancestor of s k (which must have a 
head vertex preceding s k ) then no vertex is reachable that succeeds vf . 

Therefore, for any segment s x where Sj < s s k < s s x and v\ -< then the maximum reachable 
vertex v from s x on the path r; e\ is such that v =4 v\ =^ and so s x never connects to a 
vertex with higher precedence than vj . □ 



COROLLARY 4.2.32. Following directly from Theorem 4.2.30: Given two segments Sj and 
s k where Sj < s s k and where s k is the minimal < s precedence segment such that v\ =^ then 
s k and all higher < s segments cannot be attached at two distinct vertices to the cycle defined 
by the embedding of Sj (since vf is the minimal precedence vertex within the cycle defined by 
the embedding of Sj). 



This leads to two sub-categories of embedded segments: 

Definition 4.2.33. An embedded Class 4 segment Sj is categorised as being either: 

• partially embedded if not all segments have been embedded and if no segment s k has been 
embedded such that Sj < s s k and vfc =4 v 3 ^; or 

• fully embedded if either all segments have been embedded or if a segment s k has been 
embedded such that Sj < s s k and v\ =4 v\^. 



The definition of a fully embedded segment is extended on page 53 for simplicity of notation but, 
in its current form, is particularly useful when considering the successive segments as they are 
embedded since a fully embedded segment can neither define a state where non-planarity occurs 
nor have a Class 4 segment attached to the cycle it defines; therefore fully embedded segments are 
inconsequential to the embedding of future segments and so only partially embedded segments 
need be considered. 
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Planarity Conflicts 

Considering Case 2b (page 46) - if Sk is to be embedded within the same face adjacent to its 
parent that contains Sj and where v\ -< v\ -< v\ -< v 3 h (hence, Sj is partially embedded) then 
Sj sub-divides that face such that s^'s head and tail vertex are, respectively, in the inside and 
outside face defined by s/s embedding (and neither is on the boundary of that sub-division). 
Given this, then Sk does not have a planar embedding within the same face as Sj and, hence, if 
Sk has a planar embedding then it must be in the opposite face relative to s^'s parent. 

This leads to the definition: 

Definition 4.2.34. Given segments Sj, Sj and Sk where Sj < s Sj < s s& and Sj is an ancestor 
of, and the parent of, Sj and Sk, respectively, then if v\ -< vf -< v\ then Sj and Sk are defined 
to conflict and cannot be embedded within the same face relative to Sj. 



Blocks of Conflicting Segments 

It is useful to define a structure to represent groups of segments which conflict and must be 
embedded in opposite faces adjacent to their parent; to do this we introduce the concept of a 
block of segments: 

Definition 4.2.35. A block of segments (or, simply, a block) is defined relative to a given 
segment and is a group of Class 4 segments which are partially embedded children of that given 
segment (and their partially embedded descendants) where each of those segments is assigned 
to be embedded within either the inside or outside region relative to that given segment such 
that specifying the region containing the embedding of any one segment in that block defines 
which region every other segment of that block is embedded within. 

COROLLARY 4.2.36. If a block contains more than one segment then every segment in that 
block must conflict with (and so be embedded in the opposite region to) at least one other 
segment in that block (and that each pair of segments within the block are connected by a 
series of conflicts and so: if there are an even number of conflicts in the series then the pair of 
segments must be embedded within the same region; or, if there are an odd number of conflicts 
then the pair of segments they must be embedded in opposing regions). 

COROLLARY 4.2.37. If a segment conflicts with segments on both the inside and outside of 
a block then it has no planar embedding. 



Any non-flippable segment added to a block must be embedded within the inside face relative 
that block's ancestor and so all segments within that block will then have a fixed embedding 
relative to that ancestor. This leads to an extension of the definition of segments being flippable 
to blocks such that: 

Definition 4.2.38. A block (relative to a given segment) is defined as being flippable if, 
and only if, all child segments of that given segment contained within the block are flippable - 
A flippable block defines a 2-separation where the boundary vertices are at the head vertex of 
the first segment in the block (with maximal -< precedence) and at the minimal -< precedence 
vertex of a segment within the block. 



In case 2b (page 46), it is assumed that Sj has been assigned to a block defining which face 
(adjacent to Sj) it is embedded within and then, if Sk has an embedding, it must be assigned to 
be in the same block as sj but within the opposing face. 
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Planar Embeddings of Segments 

Considering case 2c (figures 4.2.7c-e) - where Class 4 segment Sj is embedded within a given 
face adjacent to Si, the parent of Class 4 segment Sk, such that Si < s Sj < s Sk and that 
v\ =^ w t fc -< =^ v 3 h \ given this then Sj sub-divides the containing face adjacent to Sj and the 
head and tail vertices of Sk are both contained within the inside face. 

Either: Sk's head and tail vertices are both contained on the boundary Sj forms between its 
inside and outside adjacent faces - so Sk can be embedded within either region adjacent to Sj 
(case 2(c)ii, figure 4.2.7d); or at least one of s^'s head or tail vertices is on the boundary of the 
inside face adjacent to sj but is not contained on the boundary Sj forms between its inside and 
outside adjacent faces (cases 2(c)i & 2(c)iii, figures 4.2.7c & 4.2.7e). 

Considering this latter sub-case: in most instances, s& must be 
contained within the inside face relative to Sj] however, if Sj is a 
descendant of a sibling Sj> of Sk where v\ — v\ — v\ -< v 3 h — vj 2 = 
v h = v i a ~* v h ( n g ure 4.2.8) then: 

• All children of Sji are flippable - so Sj can be embedded 
within either the inside or outside face relative to Sji] 

• Sfe's head and tail vertices are identical to Sj/'s head and tail 
vertices so Sk can be embedded within either the inside or 
outside face relative to sj> (black and red embeddings); and 

• If Sj and Sk are contained within the same face relative to Sji 
then Sk is within the inside face relative to sj (highlighted 
in yellow). 



Figure 4.2.8: Permutable 
Segments Sk and Sj> 

This leads to the definition: 

Definition 4.2.39. Two Class 4 sibling segments Sj and Sk are defined to have a permutable 
embedding order (or, simply, to be permutable) when, without loss of generality, Sj < s Sk and 
where Sj and Sk have identical head vertices and identical tail vertices and have no descendants 
connecting to an ancestor other than at these shared head and tail vertices (or, succinctly, such 
that v{ = <v{ = v 3 h =v\ = p»). 

Corollary 4.2.40. If segments Sj and Sk are permutable then vl — v\ so e J h and e\ are 
outbound from the same vertex and, by the composition of Class 4 segments, v\ — vj and 
= vf ± therefore uj? = vf and vf = vf 2 therefore e 3 h \\* e\. 

Considering two permutable sibling segments Sj and Sk such that Sj < s Sk then they have that 
ordering, given corollary 4.2.40, due to an arbitrary ordering assigned to the ||* edges e 3 h and 
e\. Varying the arbitrary ||* order used to convert the partial -<* order to a total <** order 
will, correspondingly, vary the < s order and Sk can be embedded before Sj. Thus if the segment 
ordered foremost is embedded and then the later ordered segment is embedded within the inside 
region relative to that foremost ordered segment then permuting the order of those segments 
generates all permutations of Sj being inside or outside of Sk while maintaining the process that 
one segment is never embedded outside of a previously embedded sibling. 
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Conclusion 4.2.41. A pair of segments, s 3 and s k where Sj < s s k and v{ t>£ -< wjj =^ v° h 
(case 2c, page 46) is such that segment always has an embedding within the inside face of 
Sj (and if Sj is a descendant of a sibling of s k then s& is also embeddable within the inside 
face of Sj>). 

A permutable segment can be embedded within both the inside and outside face relative to 
a sibling segment; an equivalent result can be achieved by always embedding the higher < s 
precedence permutable segment within the inside face relative to the lower < s precedence 
permutable segment and instead varying the order in which those permutable segments appear 
within the < s ordering - thus achieving a consistent process that segments are always 
embedded on the inside face of a lower < s precedence segment matching case 2c. 



When a Segment and its Descendants are all Embedded 

Considering a segment's flippable descendants (which includes all segments embedded within 
the outside region relative to that segment): 

Lemma 4.2.42. If all descendants of a parent segment s p are embedded then each flippable 
child (and, recursively, descendant) segment s c is either fully embedded or has vf i = . 

Proof 4.2.43. By the definition of being flippable, each flippable child segment must either 
have: 

• v l < OT 

The next segment s n to be embedded must be a sibling of, or sibling of an ancestor of, s c where 
v h ^ v h an d so ; respectively, then: 

• v h ^ v h ^ v l ~ m wn i cn case, s c is fully embedded; or 

• v h v h and v h = v h- D 
COROLLARY 4.2.44. This latter case can be considered further such that either: 

• vf = vf x =4- U;™ =^ v h v h> m which case neither s c nor s p conflicts with s n ; 

• w ; ™ -< — vf^ -< =^ v v h -< Vfo, in which case both s c and s p conflicts with s„; or 

• w ; ™ =<; =4 vf — =4 v v h < Vfo, in which case both s c and s p will be fully embedded when 
s„ is embedded. 

Therefore, in that latter case, s p and s c will have an identical impact on the embedding of s n . 

This can be extended to consider, in exactly the same manner, when s n is any sibling of, or 
sibling of an ancestor of, s p 6 to show that in this general case that both s p and s c always have 
an identical impact on the embedding of s n . 

Given this then when s p s descendants are all embedded then all flippable descendants will be 
either fully embedded or otherwise inconsequential to the embedding of subsequent segments 
since s p can be used to determine the impact upon the embeddings of those subsequent 
segments. 



° Descendants of those siblings are not considered since they will have higher < s precedence than s n and so: 
any conflict between s p , s c and s n will occur prior to embedding that descendant; and if there is no conflict then 
either s p and s c will be fully embedded or that descendant will always be attached to the cycle defined by s n , or 
another descendant of s n , which will always be inside of s p and s c . 
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Definition 4.2.45. The definition of a fully embedded segment can be extended such that 
when a segment and its descendants have all been embedded then the descendants embedded 
within that segment's outside face can be considered to be fully embedded since they are 
inconsequential to subsequent embeddings. 



Embedding a Class 4 Segment onto its Parent with Multiple Siblings 

Previously, the embedding of a segment s k within a region 51 relative to its parent s p was 
considered compared to the segment with immediately preceding < s precedence; expanding 
this, then successively lower < s segments embedded within 51 can be considered until s p is 
reached and, hence, if 51 is the inside of s p , or if 51 is the outside of s p and s k is flippable, then 
Sk would always have an embedding. 

Given that s k is being embedded within a region 51 adjacent to its parent then the sequence of 
lower precedence segments already embedded within 51 is such that the preceding segments: 

• Are siblings of, and siblings' descendants of, s k where for s k to be being embedded then, 
given the < s ordering, each preceding sibling segment's descendants must have been 
embedded; therefore, by lemma 4.2.42, each sibling's descendants embedded outside that 
sibling will be fully embedded (see definitions 4.2.30 & 4.2.45); 

• Does not contain any segments which conflict (since each of those segments are embedded 
within the same region 5V). 

Therefore, each preceding segment within 51 is either fully embedded (either case 2a or, by 
definition 4.2.45, is a sibling's descendant embedded on the outside of that sibling) or is partially 
embedded (case 2c - either as a sibling of s k or a sibling's descendant which is embedded inside 
that sibling). 

Fully embedded segments have no impact on the embedding of subsequent segments thus to 
determine whether s k has an embedding then only the partially embedded segments need be 
considered and given that each partially embedded segment is: 

• Within R if it is the lowest < s precedence partially embedded segment within that 
sequence; or 

• Inside the immediately < s preceding partially embedded segment (conclusion 4.2.41). 
Therefore: 

Theorem 4.2.46. Each partially embedded Class 4 segment Sj embedded within a given 
region 51 adjacent to the embedding of its parent s p is contained within a sub-division of 51 
that is the inside region adjacent to any other partially embedded Class 4 segment Sj that is a 
descendant of s p where s p < s Si < s Sj. 



Proof 4.2.47. Contained in the paragraphs above. 
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Theorem 4.2.48. Given a Class 4 segment Sk being embedded within a region It adjacent 
to Sfe's parent 7 , if Sk does not conflict with the maximal < s precedence partially embedded 
Class 4 segment Sj that is already embedded within JL then s& does not conflict with any other 
segment embedded within 5L 



Proof 4.2.49. Considering the classes of segments then: 

• Each Class 1, 2 or 3 segment always has an embedding (as it is either static or rotatable); 

• Each Class 4 segment always has an embedding within the inside region adjacent to its 
parent and, if flippable, also has an embedding within the outside region adjacent to its 
parent; and 

• Once a Class 4 segment becomes fully embedded it cannot impact the subsequent 
embedding of a segment. 

So, only the case where a Class 4 segment Sk is being embedded and there are siblings, or 
siblings' descendants, which are partially embedded needs considering as all other segments do 
not impact s^'s embedding. 

Given a sequence (si, S2, ■ ■ ■ , Sj, . . . , Sj, . . .) of partially embedded Class 4 segments within a 
region 51 adjacent to a common ancestor (the parent segment of si) where si < s s 2 < s ... < s 
Si < s . . . < s Sj then Sj is embedded inside of Si is embedded inside of ... S2 is embedded inside 
of Si. Given the formulation of case 2c, then the ascending precedence of the tail vertices of 
those segments corresponds to the ascending < s precedence of those segments: 



vt 4 ■•■ vl 4 ••• vi < 



So, if a segment Sk (where Sj < s Sk and Sj is partially embedded) has an embedding that does 
not conflict with Sj then case 2c (page 46) also defines the relationship between Sj and Sk so 
v\ ^ v\ < v\ ^ v 3 h , hence, Sk does not conflict with segments si . . . s^. 

Therefore, if when Sk is being embedded within a region H adjacent to its parent and there exists 
partially embedded Class 4 sibling, or sibling's descendant, segments with lower < s precedence 
than Sk which are embedded within 31 then, of those, the segment with maximal < s precedence 
determines whether Sk has an embedding relative to all other segments within Ji. □ 



COROLLARY 4.2.50. Given a sequence (si, S2, . . . , Sj, . . . , Sj, . . .) of partially embedded Class 
4 segments within a region Ji adjacent to a common ancestor (the parent segment of si) where 
si < s s 2 < s ■ ■ ■ < s Si < s ... < s Sj then if segment s^ is tested for embedding and some of 
that sequence of segments are found to be fully embedded relative to Sk] since the ascending 
precedence of the tail vertices of those segments corresponds to the ascending < s precedence 
of those segments then the segment with the maximal precedence tail vertex is the segment in 
the sequence with maximal < s precedence (i.e. Sj). 



7 Assuming that if 31 is the outside region adjacent to Sk's parent that is flippable and can be embedded 
within 3?. 
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Performing an Embedding (and Considering Blocks) 

When embedding a Class 4 segment Sk into a region adjacent to its parent then segment Sk-i 
must just have been embedded and Sk-i is either: 

• Sfe's parent - in which always has an embedding within the inside region adjacent 
to its parent so can be trivially embedded forming a new block containing solely Sk (on the 
inside of the block since each segment always has an embedding within the inside region 
adjacent to its parent - theorem 4.2.24); or 

• A descendant of s^'s parent - in which case, there exists at least one partially embedded 
segment (either Sk-i or a sibling of Sk that is the ancestor of Sk-i) and, hence, at least 
one block of segments so s^'s embedding can be considered in relation to those blocks. 

This latter case can be considered further, however, a few useful properties of blocks can be 
noted first: 

Property 4.2.51 (Properties of Blocks). A new block is formed when a segment is 
embedded which does not conflict with any other previously embedded segment; given theorem 
4.2.48 then if a segment does not conflict with the maximal < s precedence partially embedded 
segments on the inside and outside of a previously formed block then that segment must have 
an embedding on the inside face defined by the embedding of one of those segments. Hence, if 
there are multiple blocks then the segments of the most recent block are embedded within the 
inside face of segments of the preceding block and recursively considering successive preceding 
blocks then, recursively, the segments of each successor block are within the inside face of 
segments of the preceding block. 

Using this and the fact that blocks only contain partially embedded segments then if a segment 
Sfe is such that it does not conflict with the maximal < s precedence segment on one side of a 
block then, by theorem 4.2.48, it does not conflict with any other segment on that side of the 
block and, given that the minimal < s precedence segment on that side of the block does not 
conflict with any segments of any previous block then s fe does not conflict with segments in 
either side of previous blocks. 

Returning to the embedding of a segment Sk in the case that at least one block exists relative to 
Sfc's parent then the first consideration is whether the segments which were partially embedded 
relative to the previous embedding of Sk-i are still partially embedded relative to or if they 
are now fully embedded. This can be achieved by testing the vfc against the tail vertex of the 
maximal < s precedence segment on the most recently formed block's inside or outside and it 
will be found to be either: 

• fully embedded with respect to Sk and so can be ignored in all future embeddings and 
removed from that block (if all segments of the block become fully embedded then no future 
embeddings can be impacted by the segments in that block so the block can be discarded 
and ignored) and the process can recursively consider the preceding < s precedence segment 
in the same region; or 

• partially embedded with respect to Sk and so all lower < s segments within the same region 
that were partially embedded with respect to Sk-i will still be partially embedded with 
respect to Sfe. 

If all segments in a block become fully embedded then those segments will have no impact on 
the embedding of future segments and no additional segments will be added to the block. In 
this case, the block has performed its function for the purposes of testing for planarity and plays 
no further role in the test and the previous block can be, recursively, considered; however, the 
relationships between segments captured in that fully embedded block are useful in constructing 
a cyclic edge order to represent the embedding so while it can be ignored during the rest of the 
planarity test it should not be discarded. 
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If all segments of all blocks relative to Sk's parent are fully embedded then the Sk can be 
embedding as if it was the first segment to be embedded onto its parent by creating a new 
block containing solely Sk on its inside. 

If not all segment of all blocks relative to Sk's parent are fully embedded then Sk can be 
considered against the most recently formed block which still contains partially embedded 
segments. Considering Sk against the maximal < s precedence partially embedded segments 
within the inside and outside of that block then either: 

• Sk does not conflict with either side - in which case, no partially embedded segment defines 
which region adjacent to s^'s parent Sk should be embedded in so the embedding of Sk will 
form a new block containing Sk on its inside (since Sk always has an embedding within the 
inside region relative to s fc 's parent). 

• Sk conflicts with both sides - in which case, Sk does not have a planar embedding; or 

• Sk conflicts with one side and not the other. 

The first two cases are trivial in that Sk either has or does not have an embedding; the last case 
can be split into several sub-cases, where: 

1 . The conflict is on the outside and the inside contains a partially embedded segment which 
does not conflict; 

2. The conflict is on the outside and the inside contains no partially embedded segments (so 
there is no conflict on the inside); 

3. The conflict is on the inside and the outside contains a partially embedded segment which 
does not conflict; or 

4. The conflict is on the inside and the outside contains no partially embedded segments (so 
there is no conflict on the outside). 

In cases 1 and 3 then the block contains a partially embedded segment s x which does not conflict 
with Sk- Given theorem 4.2.48 then if Sk was embedded within that face it would be embedded 
within the inside region relative to s x and, recursively, within the inside region relative to each 
segment of lower < s precedence on the same side of that block. Since the lowest < s precedence 
segment on each side of the block must be within the inside region of both sides of any preceding 
block (otherwise the contents of those blocks would either be fully embedded or would conflict) 
then Sk must also be within the inside region of all segments (on either side) of all preceding 
blocks. Therefore, in cases 1 and 3, no additional blocks need be considered. 

In cases 2 and 4 then the block contains no segments on the side of the block where there 
is no conflict. In this case, is not necessarily within the inside face of the minimal < s 
precedence partially embedded segment within the block and, hence, Sk may also conflict with the 
segments of a preceding block. One could, iteratively, consider successively lower < s precedence 
segments within that block to determine whether Sk conflicts with them all or whether there 
exists a segment where Sk can be contained within its inside face; however, this process would 
require time linear to the number of segments in the block so is inefficient. A more efficient 
implementation is to assume that Sk conflicts with all segments in that block and immediately 
consider the segments in the preceding block. This process can be applied, iteratively, considering 
Sk against successive previous blocks: 

• If Sk does not conflict with either side of the previous block then Sk can be embedded 
relative to that block (and all previous blocks) but no segment of that previous block 
defines which side Sk should Sk cannot be contained in that previous block and only 
within the most recent block - so no blocks need be considered other than the most recent 
block; 

• If Sk conflicts with segments on both sides of the previous block then Sk does not have a 
planar embedding; and 

• If Sk conflicts on a single side of the previous block then it must also conflict with all 
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segments in the most recent block 8 and an attempt can be made to coalesce the two 
blocks: 

— If the conflict within the most recent and previous blocks is on the same side then 
the blocks can be trivially coalesced. 

— If the conflict is on opposing sides of the two blocks then if the most recent block is 
flippable 9 then it can be flipped and coalesced with the previous block, however, if 
neither block is flippable then Sk is non-planar. 

If the blocks can be coalesced then the coalesced block (now the most recent block) can 
be considered against cases 1-4 (page 56) to determine if further preceding blocks need to 
be considered and potentially coalesced (alternatively halting if all blocks relative to s^'s 
parent have been considered). 

Once the blocks have been considered and, if necessary, coalesced then either a determination 
will have been made that Sk does not have a planar embedding or Sk will be being considered 
for embedding within a single block that matches one of the cases 1-4 (page 56): 

• In cases 1 and 2 (where Sk conflicts with a segment on the outside of the block but not 
the inside), given that s/. always has an embedding within the inside region relative to its 
parent, then Sk can be embedded on the inside of the block; 

• In cases 3 and 4 (where Sk conflicts with a segment on the inside of the block but not the 
outside) then: 

— If Sk is flippable then it can be embedded within the outside of the block; 

— If Sk is not flippable but the block is then the block can be flipped and Sk embedded 
within the (now) inside of the block; otherwise 

— Neither Sk nor the block is flippable so Sk does not have a planar embedding. 

One final point should be noted: When a segment Sk and its descendants are all embedded then 
there may exist segments which, at that time, are still partially embedded and may affect the later 
embedding of s^'s siblings. By corollary 4.2.50 then any descendants of Sk embedded within its 
outside region will be (or are otherwise inconsequential and can be classed as) fully embedded and 
so only those segments within the inside region can be partially embedded. Since any descendant 
of Sk must be contained within the same region relative to s^'s parent that contains Sk then those 
partially embedded segments inside of Sk can be moved from their containing block (relative to 
Sk) to the block containing Sk (relative to s^'s parent) and on the same side of the block as 
contains s&. Note: Moving these descendant segments from a block relative to Sk to a block 
relative to s^'s parent does not change whether either of those blocks is flippable. 

By iterative application of this, considering segments in < s precedence order, then all segments 
will be considered and either embedded or found not to have a planar embedding. 



8 Since precedes the tail vertex of the maximal < s segment of that previous block and the segments of the 
most recent block are within the inside region of the segments of that previous block so their tail vertices must 
have higher precedence and also conflict. 

9 If the preceding block is flippable then, since the segments of the most recent block are within the inside face 
of segments of that previous block then the most recent block must also be flippable. 
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Example Embedding 



Example 4.1.31 (page 38) (repeated in fig- 
ure 4.2.9) gives the segments generated for 
the sample graph shown in figure 3.1.1 
(page 28). Figure 4.2.10 shows the embedding 
of these segments and figure 4.2.11 shows 
the corresponding contents of the blocks; 
demonstrating a lot of the different aspects of 
embcddings previously described. 




Figure 4.2.9: Segments of Sample Graph 
Numbered in < s Order 
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Figure 4.2.10: Embedding of Segments of Sample Graph 




(a) (b) (c) (d) (e) _ (f) (g) 

Figure 4.2.11: Contents of Blocks during Embedding From Figure 4.2.10 
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Examining the embedding in more depth: 

• (a) shows the embedding of the root segment (having no parent so defining no block) which 
defines an inside (tan) and outside (brown) region. The second segment is then embedded 
forming a new block (relative to the root segment) which contains that segment on the 
inside - ordinarily this segment would be flippable but this is superseded by a requirement 
for it to be static to define which region adjacent to its parent is the inside. 

• The cycle formed by this second path defines two faces (tan and brown shown in (b)) 
and within that the third segment can be embedded. There are no previous blocks defined 
relative to its parent (the previous block being relative to the root segment) so a new block 
is formed with the third segment on its inside - both the third segment and its containing 
block are flippable. 

• (c) shows the embedding of the fourth and fifth segments. When the fourth segment is 
embedded it conflicts with the third (red) and must be added to the opposite side of the 
block from that segment; however, the fourth segment is not flippable so, instead, the block 
containing the third segment is flipped and the fourth segment added to the (now) inside 
(in the process making that containing block now- flippable). The fifth segment conflicts 
with the third (on the outside) but not the fourth (on the inside) so can be embedded on 
the inside of that block. 

• Considering (d): the algorithm has processed the second segment and its descendants so 
the segment (third) on the outside is now fully embedded (green) and the segments on the 
inside (fourth and fifth) are moved from their containing block to the block containing 
their ancestor (the second segment) on the same side as that ancestor. 

Processing the sixth segment: the first consideration is whether any previous segments have 
changed status and, relative to that segment, the fifth segment is now fully embedded while 
the fourth is still partially embedded; after that then the sixth segment can be embedded 
and it conflicts with the fourth segment (inside) and there are no segments on the outside 
of the block (nor any preceding blocks) - since the sixth segment is flippable then it is 
embedded on the outside of the preceding block. 

• The cycle formed by the sixth path defines two regions (tan and brown shown in (e)) and 
within that the seventh segment can be embedded. There are no blocks relative to the 
sixth stack so a new block is formed with that seventh segment on its inside. 

• In (f) the sixth segment and its descendants have been processed so the descendants on 
the inside of the sixth segment (i.e. the seventh segment) are moved from that block to 
the block containing the sixth segment and on the same side as that segment (i.e. the 
outside). 

The eighth segment is then considered: the fourth segment becomes fully embedded, 
removing it from the block, and then its embedding is tested and found not to conflict with 
either of the maximal < s segments on the inside or outside (being able to be contained 
within the inside face relative to both the second and seventh segments) so a new block is 
formed containing the eighth segment on its inside. 

• The final (ninth) segment's embedding (g) is tested against the most recent block and 
found to conflict with the eighth segment on the inside. However, the outside of the block 
contains no segments so it is also tested against the previous block where it finds a conflict 
with the second segment (inside) but no conflict with the seventh segment (outside) . Given 
this, then the two blocks are coalesced - since both conflicts occur on the inside then no 
block is flipped and the ninth is embedded on the outside of that block (since it is flippable). 

• The algorithm then terminates, having embedded all segments, finding the graph planar. 
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4.3 Permutations of Embeddings 

During the embedding several statuses can be assigned to segments or blocks: 



Static The root segment and, if the root segment is not of Class 2, its child with minimal < s 
precedence both have a static embedding - such that the root segment has a fixed cyclic 
direction around its inside face and that the child (or, for a Class 2 root segment, the 
leading path of bridge edges) is contained in this inside face (but does not necessarily have 
a fixed cyclic direction) . 

Rotatable Where any non-static Class 1, 2 or 3 segment can be embedded within any face 
adjacent to its head vertex. 

Reversible Where any non-root Class 2 or 3 segment can have the direction of their edges 
around their inside face reversed. 

Flippable A block of Class 4 segments (relative to a given segment) is flippable if all child 
segments (of that given segment) added to that block can be embedded within both the 
inside and outside regions adjacent to that given segment (i.e. the segments of the block 
and the path within that given segment connecting the minimal and maximal precedence 
vertices incident to those segments can be transformed via a Whitney flip to produce an 
alternate embedding) . 

Permutable A pair of Class 4 segments s x and s y are permutable if they are siblings and if 
s x has both an embedding within the inside region and an embedding within the outside 
region relative to s y , or vice versa (equivalcntly 
or, vl = vf 2 = v\ = vf 2 and e% \\* e y h ). 

Outer Reversible 

An additional case (linked to the reversible sta- 
tus) where the embedding can be permuted 10 
is for a Class 4 segment that is the descendant 
of, and has identical tail vertex as, a non- 
root Class 2 or 3 segment. In this case, that 
descendant segment has three (instead of the 
normal maximum of two for a non-permutable 
Class 4 segment) possible embeddings: inside, 
outside clockwise and outside anticlockwise 
relative to the inside of the cycle defined by 
that Class 2 or 3 segment 11 . 



, either: — vf 2 = v v h — vf 2 and vf — v\\ 




Figure 4.3.1: Possible Embeddings 
of a Class 4 Child Segment 
Attached to a Non-Root Class 3 
Segment Where Both Segment Have 
A Common Tail Vertex 



Given the construction of the segments then the minimal precedence vertex that a 
descendant of a Class 2/3 segment (where that descendant is outbound from a vertex 

10 All Class 4 children of a Class 2 or 3 segment are flippable unless they are static. A non-root Class 2 or 3 
segment, of which an outer reversible segment is a descendant of, could be a static child of the root segment 
but in no case can any of its descendants be static thus no outer reversible segment is static nor has a static 
sibling to conflict with. Therefore all Class 4 children of a non-root Class 2 or 3 segment are flippable and so if 
their descendants are planar then as the children are flipped the descendants will swap regions too and have an 
embedding within both the inside and outside regions relative to that Class 2 or 3 segment. 

11 It should be noted that the cyclic direction of the segment needs to be relative to the inside region of the Class 
2 or 3 cycle as the direction of the Class 4 segment around the inside region it defines is (when embedded outside 
its parent) constant regardless of whether it is clockwise or anticlockwise relative to the cycle's inside region. 
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on the cycle defined by that Class 2/3 segment) could potentially reach is the tail of that 
Class 2/3 segment. Therefore, if a descendant segment's tail vertex is the tail vertex of 
a Class 2/3 ancestor then all ancestors of that descendant which are also descendants of 
that Class 2/3 segment will also have the same tail vertex and be outer reversible. 

Figure 4.3.1 gives a graphical example of this case showing three dashed lines representing 
the possible embeddings of a Class 4 segment outbound from a Class 3 segment and sharing 
a common tail vertex. 

Thus, once all segments are embedded, if a segment is rotatable, reversible or permutable or a 
block of segments is flippable then alternate embeddings can be generated of the graph. 



4.3.1 Handling Flippable Segments 

If a block is flipped then the segments embedded on the inside are swapped to be on the outside 
and vice versa. Given that flipping a block is a binary state then if there are / flippable blocks 
there are 2? permutations of the embedding due to flipping blocks. 

Whether / flippable blocks are flipped or not can be represented by an /-bit binary number and 
generating all permutations of flips can be achieved by incrementing that binary number and 
querying the status of each bit. 



4.3.2 Handling Permutable Segments 



If a group of segments are all permutable then the head edges of those segments all have 
incomparable (||* ) TT-precedence and the initial < s precedence of those segments is dependant 
on an arbitrary order assigned to those head edges. Since a permutable segment (and its 
descendants) does not conflict with any other segment it is permutable with (nor that segment's 
descendants) and that all segments within the same permutable group share the same head and 
tail vertices (and their descendants are not connected to any ancestors at any other points) 
then if one order of the permutable segments produces a planar embedding then any order of 
those permutable segments will produce a planar embedding. Given this, then it is unnecessary 
to retest for planarity when embedding permutable segments in an alternate ordering - and 
by extension if, when testing for planarity, one segment of a permutable group has a planar 
embedding relative to the lower < s segments then all segments of that permutable group do 
(however, this does not prevent the descendants of any single 
permutable segment from forming a non-planar sub-graph). 

Considering the degenerate case from page 44 (figure included 
right), then the permutation of the embedding of two 
segments (black and red/green - highlighting two possible 
embeddings of that second segment on either side of the 
first) between vertices u and v can be considered such 
that segments are always embedded within a face (yellow) 
containing an edge inbound to and an edge outbound from 
the embedding segment's head vertex (u). 

• The green permutation of the embedding can be achieved by default by embedding the 
black and then embedding the second within the yellow face. 

• The red embedding requires embedding within a face where both edges on the boundary 
of the face are outbound from u; however, by permuting the order of the segments such 
that the red embedding is performed before the black then both embeddings are within 
faces with appropriate boundary directionality. 




Figure 4.3.2: Degenerate 
Embedding Case 
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In this example, additional embeddings are possible if one or both of those segments are 
considered flipped (within the white face) and this results in a special case (considered on 
the following page). 

Given a group of p permutable segments then there are p\ ways to generate an order of those 
segments. An order of a group of permutable segments can be represented by a sequence and 
by swapping adjacent elements of the sequence then all pi permutations can be generated in p\ 
swaps using the Steinhaus- Johnson-Trotter algorithm [38, 76] - this implementation is discussed 
in more depth in Chapter 5 (on page 90). In this case, the cost to generate a different permutation 
of the embedding is the cost to swap two adjacent elements in the list or, more specifically, the 
cost of finding the element within the list that is to be swapped to obtain the next permutation 
and this is shown to be a constant average time. 

4.3.3 Handling the Special Case (Permutable and Flippable and ...) 

A special case occurs when the group of permutable segments are also flippable and do not 
conflict with any other segments. In this case, all those flippable segments can be embedded 
within either the inside or outside region relative to its parent (since they are not restricted by 
either their parent or a conflict). Thus the group of permutable segments can be partitioned into 
two disjoint sub-groups corresponding to the sides of the parent within which they are embedded; 
each of those sub-groups can be re-ordered independently and segments can be moved between 
sub-groups. 

A simple method of dealing with this special case is to: 

1. Exclude the block containing that group of permutable segments from the n-bit binary 
number representing the status of the flippable blocks; and 

2. Instead, represent those segments with a sequence containing those segments and that 
group's parent segment. If a segment precedes (succeeds) its parent in the sequence then 
it is, arbitrarily, in the outside (inside) region relative to its parent and the order of the 
segments within the sub-sequences preceding and succeeding the parent determines the 
embedding order within that region. 

Thus, for a group of p permutable segments then, in this special case there are (p+l)\ possible 
arrangements of embeddings. 

When the Special Case Contains a Static Segment 

A further sub-case of that special case occurs when the group of permutable segments contains 
a static segment 12 . In this specific instance then the permutable segments can move freely 
between the inside and outside regions relative to the root segment with the exception of that 
static segment which must always be within the inside region; however, the order of those sub- 
groups of inside and outside segments can be freely re-ordered (including that static segment). 

This can be represented as per the special case, above, with the added constraint that the parent 
(root) segment and the static child segment are initially ordered such that precedence within the 
sequence of those two segments defines the static child segment to be within the inside face and, 
during subsequent swaps of adjacent segments to reorder the sequence, that the parent and static 
child segments are never swapped. In this sub-case, for a group of p permutable segments then 
there are 1 /2(p+ 1)! possible arrangements of embeddings (since there are (p + 1)! unconstrained 

12 In which case, the group's parent is the root segment and is of Class 3 — since the only Class 4 segments are 
defined to be permutable so the root segment must be of Class 2 or 3 to have a Class 4 child and if the root 
segment was of Class 2 then its child would not be static. 
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orderings and in half those orderings the static child will have an invalid precedence compared 
to its parent). This can be implemented through careful initialisation of the sequence and by 
using the Steinhaus- Johnson- Trotter permutation algorithm as discussed in the next chapter. 

Figure 4.3.3 shows an example graph where the 
edges are coloured by segment such that: the 
root segment is black; it has two permutable, 
flippable children which do not conflict with 
any other segments that are coloured orange 
(static) and blue (not static); and each of 
these three segments has a pair of children 
which conflict but are both flippable thus 
defining three flippable blocks. There are 2 3 
embeddings from varying whether blocks are 
flipped and 3! /2 embeddings from re-ordering 

3 x3!/ 




permutable segments giving a total of 2 x 3!/2 = 
24 different embeddings (shown in figure 4.3.4). 



Figure 4.3.3: Example Graph with 3 Flippable 
Blocks and 2 Permutable, Flippable, 'Non- 
Conflicting Segments Including the Static 
Child Segment 




Figure 4.3.4: All Permutations of Example Graph in Figure 4.3.3 
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4.3.4 Handling Reversible Segments 

Whether a segment's cyclic direction is reversed is, similar to whether a block is flipped, a binary 
state. Given this then if there are r reversible segments then there are 2 r permutations of the 
embedding due to reversing segments. 

Whether r reversible segments are reversed or not can be represented by an r-bit binary number 
and generating all permutations of reversals can be achieved by incrementing that binary number 
and querying the status of each bit. 

4.3.5 Handling Rotatable Segments 

Initially, Class 1 , 2 or 3 segments can be considered independently such that each segment either: 
forms the root segment of a biconnected component (with, Class 2, or without, Class 3, a leading 
path of bridge edges) with its Class 4 descendants; or forms a simple path (Class 1). 

Rotatable segments can be partitioned into two sub-categories where the segment and its 
descendants connects to its head vertex with: a single (bridge) edge (Class 1 or 2 segments); 
or, multiple edges (Class 3 segments). Further to this, rotatable segments can be considered 
grouped by sub-category and by distinct head vertices. 

When considering the embedding of a group of rotatable segments with a common head vertex 
v then the assumption is made that there is a fixed cyclic order of edges incident to v generated 
by an fixed embedding of the rotatable segment's common parent segment (containing v) and 
all that parent's Class 4 descendants which are not descendants of a rotatable descendant of 
that parent. This can be fixed cyclic order can be represented by the sequence (ei, ei, ■ ■ ■ , e„) 
where ei is embedded such that it is immediately clockwise about v from e„ and where for all 
2 < x < n then e x is embedded such that it is immediately clockwise about v from e^x — 1). 

Onto this fixed cyclic edge order can be attached: 

1. The group of Class 3 rotatable segments and their descendants; then 

2. The group of Class 1 and 2 rotatable segments. 

Handling Non-Root Class 3 Segments and Descendants 

Considering the attachment of a non-root Class 3 segment to its parent segment (and the 
biconnected component formed by that parent and its Class 4 descendants) . Initially, each non- 
root Class 3 segment and its Class 4 descendants can be considered independently of its parent 
assuming 

A Class 3 segment contains two edges (its head and tail) incident to its head vertex; additionally, 
its descendants can connect to the head vertex either within the inside or outside region relative 
to that segment. Any descendant of that Class 3 segment whose tail vertex is that Class 3 
segment's head vertex must, by the relative precedence of the descendant's head and tail vertices, 
be a Class 4 segment; therefore, those descendants must be, by definition outer reversible and 
may be flippable or permutable but cannot be rotatable or reversible. 

Since an outer reversible segment has one embedding inside the cycle defined by the class 3 
segment then it always defines permutations of the embedding and defines them in different 
numbers depending on whether it is inside or outside of the cycle. This is shown in figure 4.3.5 
(below) since when the three dashed segments, connecting to the head vertex of the Class 3 
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cyclic segment, are in its outside face there are four (a-d) possible embeddings (one for the 
cycle and one for each of those segments in the outside face) but when they are flipped to be 
embedded within the inside face there is a single embedding (e) . 




(a) (b) (c) (d) (e) 



Figure 4.3.5: Four Possible Embeddings (a-d) Within the Outside Face and When Flipped (e) 
a Single Embedding Within the Inside Face 

Considering the embedding of a sequence (si, S2, ■ ■ ■ , s m ) of m Class 3 segments with a common 
head vertex where the sequences • . • , i m ) and (oi, o%, . . . , o m ) represent the numbers of 

outer reversible segments emanating from each correspondingly numbered Class 3 segment 
within, respectively, the inside and outside faces of those segments. Also given that the head 
vertex has a cyclic order (ei, e2, . . . , e n ) of n edges already embedded where those edges represent 
the embedding of the parent segment and Class 4 descendants (as described above) then each 
Class 3 segment must be embedded between an edge and, without loss of generality, the edge 
immediately clockwise from it (since those edges initially considered form part of a biconnected 
component and so a Class 3 segment's head and tail edges cannot "straddle" one or more edges 
previously embedded as part of a biconnected component without crossing the boundary of a 
face and being non-planar). 

When the first segment s\ is embedded, it can be contained in any of n faces and, given its 
embedding within one such face in a fixed cyclic direction, then there will now by n + 2 faces. 
Considering the descendants of S\ then if none terminating at its head vertex (i.e i\ + o% = 0) 
then nothing else needs to be considered; however, if it has descendants terminating at its head 
vertex then all of those descendants can be flipped so there are (1 + Oi) possible embeddings 
when not flipped and (1 + ii) possible embeddings when flipped. Giving a total of n(2 + i\ + Oi) 
possible embeddings (or n possible embeddings if there are no descendants). This is further 
complicated with those descendants are not flipped as a group but there arc multiple blocks 
which can be flipped independently. 

When the second segment s 2 is considered, it can be embedded between any pair of cyclicly 
adjacent edges around that head vertex; which is now (n + 2 + i\ + o\) edges. However, it 
can also be embedded such that one of the interior faces defined by its embedding contains the 
embedding of S\. Therefore, assuming i 2 + o 2 > then, s 2 has (n + 3 + i\ + Oi)(2 + i 2 + o 2 ) 
possible embeddings. 

This rapidly becomes a very large number of possible embeddings and the embedding of 
successive segments can depend on the embedding of previous segments and the arrangement of 
their descendants. 
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Figure 4.3.6 





Figure 4.3.6: Example Permutations of Class 3 Segments 



Figure 4.3.6 gives an example, spread over three panels, of this. A vertex is first considered with 
all its ancestors and incident class 4 children embedded (black edges) and then the class 3 children 
are attached. The example shows the attachment of five class 3 children (red, green, blue, orange 
and purple) in an arbitrary attachment. Two, orange and purple, are attached between distinct 
pairs of adjacent incident edges, so assuming a fixed cyclic direction, have a unique embedding; 
however, the other three are all embedded between the same pair of adjacent incident edges and 
can be attached in any order as well as having regard for descendants of those segments. The 
middle panel shows the attachment of the red class 3 segment (with a given cyclic direction) and 
some example (faded red) descendants (with a fixed outer reversible order of attachment) . The 
right panel gives an example attachment where the remaining two class 3 segments arc attached 
between different pairs of adjacent edges - however, those segments could have equally been 
embedded between any other pair of adjacent edges (even between the same pair, repeating the 
consideration given in the middle panel). 

Therefore, the possible embeddings of a class 3 segment is dependant on prior embeddings and 
unlike class 1, 2 or 4 segments cannot be considered independently. For these reasons, there 
is not an immediate solution to the problem of predicting the total number of embeddings for 
multiple Class 3 segments (especially with outer reversible descendants) so it is difficult to prove 
that, on average, a time bound linear to the number of permutations and the number of edges 
(or segments) can be achieved. 

One possible avenue of investigation for creating an algorithm to all possible embeddings of class 
3 segments is to form the sequence (ei, €2, ■ ■ ■ , e„, s\, S2, ■ • • , s m ) and then swapping adjacent 
elements of the sequence, using the Steinhaus- Johnson- Trotter permutation algorithm, with the 
added constraint that e\ precedes ei which both precede which ... all precede e„ within that 
sequence (i.e. the algorithm never swaps e x -\ and e x ) but it is allowed to intersperse the order 
of edges with segments in any order. Given this then ( n + m Y-/n\ permutations of that sequence 
can be generated defining which segments are embedded between which pair of cyclicly adjacent 
edges and the relative order of those segments between each pair. 

Considering the sub-sequence (. . . , e a _i, s a , Sb, s c , . . . , e x , . . . , ) then it can be considered to mean 
that s a is embedded clockwise (Cj) of e x -i and Sf, is embedded clockwise or inside of s a and 
s c is embedded clockwise or inside of Sf,. The state where Sb is considered anti-clockwise ((!)) 
or outside of s a can be achieved when the sequence is re-ordered such that Sb precedes s a ; thus 
offering some simplification. 

From this then those segments embedded within the same face (bounded by two adjacent incident 
edges) can be considered independently from all other segments embedded within different faces. 
The first segment s a has, given a fixed cyclic direction, a unique embedding and its children can 
be embedded in a given outer reversible manner. Then the next segment Sb can be embedded, 
relative to the vertex being considered, clockwise of the most clockwise descendant of Sb (or 
Sb most clockwise edge if it has no descendants embedded on the outside) and achieving all 
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possible embeddings can be achieved by iterating, anti-clockwise, through each adjacent face 
formed by s a and its descendants. Similarly s c can be embedded clockwise and outside of the 
initial placement of its predecessor Sb and all possible embeddings can be achieved by iterating 
through all faces that are inside of, or clockwise of, its predecessor s^. 

The problem for this method is to create a data structure that will be able to handle the iterative 
repositioning of s&, s c and their descendants and this will require further work to prove that 
this process for embedding multiple class 3 segments can be achieved in linear time. As such, 
the empirical testing performed in chapter 7 does not consider multiple permutations of class 3 
segments. 

Handling Class 1 and 2 Rotatable Segments 

For this, it can be assumed that all non-Class 1 or 2 segments have been embedded and there 
is a fixed cyclic order (ei, e2, . . . , e„) for those edges. 

A Class 1 or 2 segments's head vertex is incident to a single edge within the sub-graph formed by 
that segment and its descendants. Considering two Class 1 or 2 segments Si and 82, outbound 
from a common head vertex, then when embedded: si is in the outside region relative to s 2 ; 
and S2 is in the outside region relative to si - since a Class 1 or 2 segment cannot be inside a 
region defined by another Class 1 or 2 segment then the issues with Class 3 segments are not 
present and they have a comparably trivial embedding. 

Given a sequence (si, 82, ■ ■ ■ , s m ) of m Class 1 and 2 segments then the ordering of the 
embedding of these segments about their head vertex can be handled simply by constructing the 
(ei, e 2 , . . . , e„, si, s 2 , . . . , s m ) and then swapping adjacent elements of the sequence (for example, 
using the Steinhaus- Johnson- Trotter permutation algorithm) with the added constraint that e\ 
precedes e 2 which both precede 63 which ... all precede e„ within that sequence (i.e. the 
algorithm never swaps e x ^i and e x ) but it is allowed to intersperse the order of edges with 
segments. The result of this ordering is that ( n + m )'/n\ permutations of that sequence can be 
generated defining which segments are embedded between which pair of cyclicly adjacent edges 
and the relative order of those segments between each pair. 
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4.4 Generating a Cyclic Edge Order 

Given an embedding of a graph then a cyclic edge order of that embedding is an clockwise / anti- 
clockwise ordering of the edges incident to each vertex which represents that embedding. 
Algorithmically. it can be represented such that the edges incident to each vertex define a 
doubly-linked circular list such that each forward (backwards) link from a given edge in the list 
represents the link to the next edge clockwise (anti-clockwise) about that vertex; therefore each 
non-looping edge is contained in two distinct doubly-linked lists (one for each incident vertex) 
and each looping edge has two entries in the same doubly- linked list. 

It is useful to recall a corollary [32, pg. 551-552] to the Jordan 
Curve Theorem that: Jordan arcs A, B and C, which have 
the same endpoints (jp and q) but do not otherwise intersect, 
then if the clockwise orientation of the arcs about p is in the 
order (A,B,C) then the clockwise orientation of those arcs 
about q is in the order (A,C,B) (figure 4.4.1). 

In addition, it is useful to define the concept of cyclic 
direction for cyclic/biconnected segments: 

Definition 4.4.1. Given a Class 2, 3 or 4 segment then that segment defines the boundary 
between an inside and an outside region (from definition 4.2.18) and that segment's cyclic 
direction is defined to be whether its edges are directed clockwise or anti-clockwise around that 
inside region. 



4.4.1 Initial Cyclic Edge Order (Solely Within a Segment) 

Not considering the attachment of descendant segments to their ancestors then: 

Definition 4.4.2. Each non-root vertex has an immediately preceding (tree) edge inbound 
to that vertex which is contained in the same segment that can be defined to be its parent 
edge for that vertex. Similarly, each degree 2 or more vertex has an immediately succeeding 
(minimum <** precedence) edge outbound from that vertex which is contained in the same 
segment that can be defined to be its stem edge. Together these edges define the initial cyclic 
edge order for a vertex such that the next edge both clockwise and anti-clockwise from the 
parent (stem) edge is the stem (parent) edge. 

This initial cyclic edge order can be expanded as child segments and their descendants are 
considered for attachment to the embedding. 

Considering the segment's tail when it is contained in the same segment then, in the case of: 

• A Class 1 segment (assuming the graph is not a single vertex), its tail vertex has degree 1 
so, trivially, the cycle of edges about that tail vertex consists of a single edge; 

• A Class 2 segment, its tail vertex has both a parent and stem edge, so its tail is a third 
edge incident to this vertex; if the segment has a clockwise (anti-clockwise) cyclic direction 
then the tail edge can be inserted into the tail vertex's cyclic edge order clockwise (anti- 
clockwise) from the stem edge; and 

• A Class 3 root segment then the root vertex has no immediately preceding edge but, within 
that segment, the tail (cotree) edge is inbound to the root vertex and, for simplicity, the 
parent edge of the root vertex can be defined to be the root segment's tail edge. 

The attachment of head edges and other cases of tail edges is considered in more depth in the 
following pages. 
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4.4.2 Generating a Cyclic Edge Order for a Biconnected Component 

A biconnected component is formed of a cycle (defined by a Class 2 or 3 segment) and zero or 
more Class 4 segments. 

Calculating the Cyclic Direction of a Class 4 Segment 

A Class 4 segment branches from its parent (which must be 
of Class 2, 3 or 4 and defines the boundary between an inside 
and an outside region within one of which the Class 4 segment 
is embedded) therefore considering the cyclic direction of 
both segments (figure 4.4.2) then: 

• If the parent is clockwise (black dashed arc) and 
the child is inside/outside (red/blue dashed arc, 
respectively) then that child's cyclic direction is 
clockwise / anti-clockwise (respectively) ; and 

• If the parent is anti-clockwise (grey dashed arc) 
and the child is inside/outside (blue/red dashed arc, 
respectively) then that child's cyclic direction is anti- 
clockwise / clockwise (respectively) . 

Alternatively, this can be simply defined such that: 

Definition 4.4.3. Given a Class 4 segment that is embedded within the inside (outside) 
region defined by its parent then that segment has the same (opposite) cyclic direction as its 
parent. 

Therefore, by assigning an arbitrary direction to the Class 2 or 3 segment that is the root 
segment of the graph (or of the biconnected component) and having performed an embedding 
of the graph (such that each Class 4 segment is assigned to be either on the inside or outside 
region of its parent) then each Class 4 segment will have a well defined cyclic direction. 




---KX— ' 

Figure 4.4.2: Segments With 
Clockwise (Red) and Anti- 
Clockwise (Blue) Cyclic 
Direction Connecting to Parent 
With Clockwise (Black) or 
Anti-Clockwise (Black and 
Grey) Cyclic Direction 



Generating a Cyclic Edge Order for Class 4 Segments 

Considering the < s order then the first (designated as "that 
parent") segment to contain a vertex v defines its initial cyclic 
order (usually defining an inbound and an outbound edge). 

A Class 4 segment s x can either connect to a vertex v in that 
parent via: 

• Their head edge where v is s^'s head vertex; or 

• Their tail edge where v is s^'s tail vertex and can be 
sub-categorised into: 

— When s x has no ancestor (except that parent) 
inbound to v; 

— When s x has a Class 4 ancestor (other than that 
parent) inbound to v; or 




/s 2 



,'S\ 



Figure 4.4.3: Angles From 
Parent & Stem Edges To 
Segments With Increasing 
< s Precedence 
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— When s x has a Class 3 ancestor (other than that 
parent) inbound to v so s x is outer reversible. 

Considering the attachment of s x at its head vertex then either s x is the first child attached to 
that side of the segment at v or there will exist a previous segment and, by theorem 4.2.48, the 
latter segment will be added within the inside face of the previous. In both cases: 

Definition 4.4.4. A segment's head edge can be added to the cyclic edge order about its 
head vertex v by inserting it into the cyclic order adjacent to v's parent edge in the opposite 
cyclic direction to the embedding of that segment. 

Figure 4.4.3 gives a graphical representation of this such that the parent segment s\ is embedded 
in a clockwise cyclic direction and segment S2 is embedded within the inside region so has 
the same (clockwise) cyclic direction and the head edge is the opposite (anti-clockwise) cyclic 
direction from the head vertex's parent edge (angle a). Segment s 3 is also embedded in the same 
region; is outbound from the same head vertex; and has a the same clockwise cyclic direction. 
Given this then s 3 's head edge is also anti-clockwise (angle /3) from the head vertex's parent 
edge (and it can be noted that (3 < a). 

Considering the attachment of s x at its tail vertex v where s x has no ancestor that inbound to 
v (except that parent) then either: 

• s x is a child of that parent and no ancestor exists (and can note that s x is of Class 4 so 
v ~< v % and the most recent outbound edge from v is contained in that parent) ; or 

• s x is a descendant of a child s c of that parent (and can note that v — vf =4 v £ -< so 
either: v — and the most recent outbound edge from v is in s c ; or v -< and the most 
recent outbound edge from v is contained in that parent). 

In both case, s x can be considered relative to the most recent outbound edge e from v where 
that most recent edge is contained in a segment designated s r then s x must be either: a child 
of s r ; or a descendant of a child of s r and, in this latter case, since s x terminates at v but no 
other ancestor of s x does then that child of s r must terminate at a vertex preceding v and so 
s x is not flippable and is within the inside region of that child of s r (and all other ancestors of 
s x back to that child) so has the same cyclic direction as that child. Therefore: 

Definition 4.4.5. A segment's tail edge, where no ancestor of that segment contains an 
edge inbound to that segment's tail vertex (except within the first segment to contain that 
vertex), can be added to the cyclic edge order about its head vertex v by inserting it into the 
cyclic order adjacent to the most recent outbound edge from v in the same cyclic direction as 
the embedding of that segment. 

Figure 4.4.3 gives a graphical representation of this such that the parent segment s\ is embedded 
in a clockwise cyclic direction and segment s 2 is embedded within the inside region so has the 
same (clockwise) cyclic direction and the tail edge is in the same (clockwise) cyclic direction 
(angle a') from the head vertex's stem edge which is the most recent outbound edge. 

Considering the case where s x is being attached at its tail vertex v and s x has a Class 4 ancestor 
s a (excluding that parent segment) that is inbound to v (if there are multiple ancestors inbound 
to v then s a is the maximal < s precedence ancestor). Since v = vf — vf then s a is the parent 
of s x (since if it is not then s^'s parent would also have its first low point at v and so s a would 
not be the maximal < s precedence segment). 

The head edge of s x is inserted into the cyclic order about v% such that it is inserted adjacent 
to v^'s parent edge (which is contained in s a ) and in the opposite cyclic direction to that of s x . 
Following the boundary of the region containing the arc between v^'s parent edge and then 
the attachment to v is not performed relative to ef but to the edges adjacent to e" within the 
cyclic order around v at the instant when e" was ordered. 
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Figure 4.4.4 gives two examples of this: 

• Segment S2 is embedded outside of segment si (in an 
anti-clockwise direction) and both share a common 
tail vertex. The angles a and a' show the angles 
within the inside region (relative to S2) adjacent to S2's 
head and tail vertices, respectively. S2's head edge is 
ordered clockwise of v^'s parent and S2's tail edge is 
ordered anti-clockwise of the edge that was immediately 
clockwise of Si when si was embedded (in this case v^'s 




CX- 



Figure 4.4.4: Angles From 
Parent & Neighbouring Edges 
To Segments With Increasing 
< s Precedence 



parent edge). 

• Segment S3 is embedded inside segment s\ (in a 
clockwise direction) and /3 and j3' show the angles 
within the inside region (relative to S3) adjacent to S3's 
head and tail vertices, respectively. S3's head edge is 
ordered anti-clockwise (opposite to S3's cyclic direction) 

of v^'s parent and S3's tail edge is ordered clockwise (same as S3's cyclic direction) of the 
edge that was immediately anti-clockwise (opposite to S3's cyclic direction) of s\ when Si 
was embedded (in this case vj's stem edge). 

This can be implemented such that: 

Definition 4.4.6. When a segment's tail edge is inserted into the cyclic edge order the 
pair of edges immediately clockwise and anti-clockwise can be added to a stack. When all 
descendants of that segment have been given a cyclic ordering then the entry can be removed 
from the tail of the stack. 



If when a segment's tail edge is added to the cyclic order about a vertex that vertex contains no 
pairs of neighbouring edges on the stack then no ancestors have been connected to that vertex 
at their tail edges so the edge can be processed as per definition 4.4.5 and an entry placed on 
the stack containing the neighbouring edges. 

If the vertex contains an entry on the stack then an ancestor has been connected to that vertex 
at its tail edge and the new segment's tail edge can be added to the cyclic order around that 
vertex such that if the new segment's cyclic direction is clockwise (anti-clockwise) then the tail 
edge is added to the cyclic order clockwise (anti-clockwise) from the edge on the stack that was 
anti-clockwise (clockwise) from the embedding of the previous ancestor. 



Given this then a cyclic edge order can be generated for a biconnected graph. 



Chapter 5 

The Algorithm 



This chapter takes the theoretical process defined over the previous two chapters and details 
how an efficient algorithm can be constructed. The algorithm is broken down into small sections 
corresponding to the sections in the previous chapters; these sections deal with: 

• Expected Data Structures; 

• Tremaux Tree Generation; 

• Segment Generation; 

• Planarity Testing and Permutation Generation; 

• Permutation Manipulation; and 

• Planar Embedding Generation. 

The theory in the previous two chapters justifies why the algorithm works and as such: 

• By performing a DFS and giving the vertices numbers, and edges direction, as they are 
visited then a Tremaux Tree is formed and has all the associated invariant properties 
thereof; 

• By bucket sorting the edges according to low points (and an arbitrary order defined by 
the data structure used) then the edges are in <** order and a second DFS results in the 
segments being generated (and being in order of < s ); similarly, with all the associated 
invariant properties that this gives; then 

• Given all these invariant properties then a simple iterative process to check segments for 
planarity /non-planarity and to embed segments can be used to generate an embedding. 

Therefore, while the proof of the invariant properties relating to the Tremaux Tree, the segments 
and the segment's ordering is quite involved, the resulting algorithm can assume the existence 
of these properties through correct construction of the segments and becomes a relatively simple 
iterative process. 
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5.1 Depth First Search 

Lemma 5.1.1. Performing a Depth-First Search (DFS) on a graph defines a Tremaux Tree. 

Proof 5.1.2. Bondy and Murty [4, pg. 141-142] prove (using a timing function and the 
times each vertex is first and last visited) that the DFS-tree T of (multi-) graph S is such that 
every edge of S joins two vertices which are related (such that one vertex is contained in the 
path within the spanning tree from its root to the other vertex) in 7 - this is the fundamental 
definition of a Tremaux Tree (see page 28). 

This proof is accepted with the caveat that Bondy and Murty do not consider looping edges; 
however, each looping edge has two related end-points (since each vertex is related to itself) 
so, trivially, is part of a Tremaux Tree. □ 



Given lemma 5.1.1 then DFS is the fundamental building block of this planarity testing 
algorithm; in fact, each phase uses a separate DFS: first, to generate a Tremaux Tree; then on 
the (now directed) Tremaux Tree to generate the segments; thirdly on the segment's hierarchy 
to generate an embedding; and, after setting whether each block is flipped and the order of 
permutable segments, a final DFS on the segment's hierarchy to set the cyclic edge order. 



Two equivalent implementations of a DFS 
algorithm are presented: one recursive (list- 
ing 5.1.1); the other iterative (listing 5.1.2). 
The recursive algorithm is slightly easier to 
comprehend and shorter; however, execution 
of the recursive version usually exceeds the 
memory allocated to the call stack (creating 
a stack overflow) long before either version 
would exceed the total available memory. As 
such, the iterative version is preferred but are 
interchangeable if memory issues are not of 
concern. 

Two place holder functions DFSPreOrder 
and DFSPostOrder are included to represent 
when each implementation starts and finishes 



processing tree and cotree edges. 
Listing 5.1.1: Recursive Depth-First Search 


procedure RecursiveDFS ( u ) { 


MARK 


U AS VISITED 


for each ( e e v. connected ) { 


IF 


( e IS UNVISITED ) { 




MARK e AS VISITED 




let e = {u,v} 




IF ( V IS UNVISITED ) { 




MARK e AS TREE EDGE 




DFSPreOrder ( e ) 




RecursiveDFS ( v ) 




DFSPostOrder ( e ) 




} ELSE { 




MARK e AS COTREE EDGE 




DFSPreOrder ( e ) 




DFSPostOrder ( e ) 




} 


} 




} 




} 




RecursiveDFS ( root ) 




J 



Listing 5.1.2: Iterative Depth-First Search 

procedure IterativeDFS ( root ) { 

LET S = EMPTY STACK 
MARK root AS VISITED 

for each ( e £ root . connected [in 

REVERSE ORDER] ) 
PUSH e ONTO S 

WHILE ( S IS NOT EMPTY ) { 

peek at e on S 

IF ( e IS UNVISITED ) { 
MARK e AS VISITED 
LET e = {u,v} WHERE ( V IS 
UNVISITED OR V =<! U ) 
IF ( V IS UNVISITED ) { 
MARK V AS VISITED 
MARK e AS TREE EDGE 

DFSPreOrder ( e ) 

FOR EACH ( e ' £ 

v . connected \{ e} [in 

REVERSE ORDER] ) 

PUSH e ' ONTO S 
} ELSE { 

MARK e AS COTREE EDGE 

DFSPreOrder ( e ) 
DFSPostOrder ( e ) 
POP e FROM S 

} 

} ELSE { 

IF ( e IS TREE EDGE ) 

DFSPostOrder ( e ) 
POP e FROM S 

} 



} 



Provided the place holder functions have 
a constant execution time then the DFS 
algorithm has an 0(V + £) execution time 
[32]. 
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5.2 Expected Data Structures 



The algorithms listed in the following sections expect there to be data structures defined to 
represent a vertex and an edge. A template detailing the attributes, and respective initial 
values, is included below. 



CLASS VERTEX { 

attribute connected 

attribute index 

attribute parent 

ATTRIBUTE lowPointl 

ATTRIBUTE lowPoint2 

ATTRIBUTE Outbound 



list op edges pre— populated with all connected edges 

( UNVISITED OR N ) INITIALLY UNVISITED 

( EDGE OR NULL ) INITIALLY UN ASSIGNED 

VERTEX INITIALLY this 

VERTEX INITIALLY this 

list op edges initially empty 



A vertex is assumed to have a list of connected edges that is pre-populated prior to the planarity 
test and during pre-processing to generate the Tremaux Tree: 

• Each vertex is assigned, as the DFS algorithm performs the search: a unique index, 
corresponding to the DFS pre-order; and, with the exception of the root vertex, a parent 
edge - which is the inbound tree edge via which that vertex was first reached by the DFS 
algorithm (the algorithm is started at the root vertex so in this special case the root vertex 
is defined to have a null parent). 

• Each vertex calculates, as the DFS algorithm backtracks, its first and second low points. 

• During bucket sorting, post DFS, those connected edges which have been assigned 
directionality outbound from that vertex are ordered and assigned to the outbound list. 



CLASS EDGE { 

attribute connected «— unordered pair of [ pre— populated ] incident vertices 

ATTRIBUTE Status <— ( UNVISITED OR TREE OR COTREE ) INITIALLY UNVISITED 

derived attribute DFSFrom 

DERIVED ATTRIBUTE DFSTo 

method setStatus( status' ) { 
status <— status 1 

if ( status ' = unvisited ) { DFSFrom -f— DFSTo «— unassigned } 
else { 

let {u,v} = connected where u =<< v 

if ( status 1 = tree ) { DFSFrom 4- u, DFSTo <- v } 
else { DFSFrom -f- v , DFSTo <- u } 

} 

} 



method otherEnd( v in connected ) { 

28 let {x,y} <— connected 

29 IF ( V = X ) RETURN y 
ELSE RETURN X 

} 



Each edge is assumed to have been, similarly, initialised prior to planarity testing such that 
its connected attribute contains the (unordered) pair of vertices that edge joins. During DFS, 
each edge is assigned the status as either a tree or a cotree edge and from this, and the relative 
precedence of the incident vertices, a direction can be derived for that edge such that it is 
outbound from one incident vertex and inbound to the other. 
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5.3 Tremaux Tree Generation Algorithm 

The first phase of the planarity testing is to pre-process the graph; this is performed by the 
depth-first search and subsequent bucket sort algorithm (listing 5.3.1); it is an equivalent non- 
recursive implementation to Hopcroft and Tarjan's [32. pgs. 553 & 555-556] recursive DFS and 
bucket sort. 

The depth-first search is used to: 

• Partition the edges into the sets of tree and cotree edges; 

• During DFS pre-ordering, assign each edge a direction and. if a tree edge, assign the 
unvisited vertex a unique index corresponding to the DFS ascending pre-order; 

• During DFS post-ordering, propagate the vertices' low points up the tree as the algorithm 
backtracks; and, using these low points, assigns edges to buckets. 

After the DFS, the bucket sort then populates the list of outbound edges for each vertex. 

^ Listing 5.3.1: Depth-First Search and Bucket Sort Pre-Processing Algorithm 

procedure DFSandBucketSort ( S (V, £) , root ) { 

LET S = EMPTY STACK 

LET bucket = ARRAY OF (2|V| — 1) EMPTY LISTS 
LET i = 1 

root . parent <— null 
root . index <— i 

for each ( e 6 root . connected [in reverse order] ) 
push e onto S 

WHILE ( S IS NOT EMPTY ) { 
PEEK AT e ON S 

if ( e. status = UNVISITED ) { 

let e = {u,v} where ( v. index = unvisited or v =<; u ) 

15 if ( v. index = unvisited ) { 

16 v. index i <— i + 1 
v . parent <— e 
e.setStatus( tree ) 

19 for each ( e' g v . connected \{e} [in reverse order] ) 

20 push e ' onto S 

} ELSE { 

e.setStatus( cotree ) 
UpdateLowPoints ( e ) 
AssignEdgeToBucket ( e ) 
pop e from S 

} 

27 } ELSE { 

28 if ( e. status = TREE ) { 
UpdateLowPoints ( e ) 
AssignEdgeToBucket ( e ) 

} 

32 POP e FROM S 

33 } 
} 

for ( b <- 1 . . . 2|V] - 1 ) 

36 for each ( e g bucket (b) ) 

37 append e to tail of e . DFSFrom . out bound 



The procedures UpdateLowPoints and AssignEdgeToBucket are included on page 78. These 
two procedures correspond to the place holder function DFSPostOrder in listing 5.1.1 and the 
DFSPreOrder place holder function corresponds to lines 16-17. 
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The output of the algorithm is such that: 

• Each vertex is processed, either: 

— Prior to starting the DFS search, if it is the root vertex; or 

— When the first edge incident to that vertex is processed, if it is a non-root vertex. 
In both cases, processing the vertex: 

— Assigns it an index (lines 6 & 16) higher than all previously assigned indexes (hence, 
giving it a unique index); 

— Assigns the incident edge to be the vertex's parent (line 17) or a null parent in the 
case of the root vertex (line 5) ; and 

— Adds all other incident edges to the stack § (lines 8-9 & 19-20) for subsequent 
processing (hence, all edges on § are incident to at least one visited vertex). 

• When processing an edge connecting a visited to an unvisited vertex it is designated to be 
a tree edge; and the unvisited vertex is processed (as described above). 

Since tree edges always connect to an unvisited vertex (which immediately is visited) the 
the sub-graph of tree edges forms a (rooted) spanning tree. Also, given that vertices are 
assigned successively higher unique indexes, any vertex u on the path of tree edges from 
the root vertex r to any other vertex v has relative precedence and indexes such that 
(u -< v u.index < v. index) and (u = oO u.index = v. index). 

• When processing an edge connecting two visited vertices then it is designated to be a 
cotree edge. A cotree edge (y -2> u) appears on stack § twice before it is processed; once 
when vertex u is processed (and v is unvisited) and is added again when v is processed - 
if the first incidence was processed before the second was added to the stack then the edge 
would connect a visited to an unvisited vertex which contradicts the original assertion that 
the edge connects two visited vertices. 

Considering the time complexity of the DFS algorithm: 

• Each edge is added to stack § once if it is a tree edge or twice if it is a cotree edge. 

• Each edge on stack S is processed: 

— Twice if it is a tree edge - once to assign it to be a tree edge (lines 15-21) and then 
again, during backtracking, when it is removed from the stack (lines 28-32); or 

— Once, for each time it appears on the stack, if it is a cotree edge - when it is assigned 
to be a cotree edge and removed from the stack (lines 21-26 & 32). 

• Since at each iteration of the DFS algorithm, either: 

— An unvisited edge is designated to be a tree edge (and the connected unvisited vertex 
is processed adding all incident edges to the stack); 

— An unvisited edge is designated to be a cotree edge then has its low points updated 
and is added to a bucket before being removed from the stack; 

— A visited tree edge has its low points updated and is added to a bucket before being 
removed from the stack; or 

— A visited cotree edge is removed from the stack. 

Therefore, provided the procedures UpdateLowPoints and AssignEdgeToBucket execute in 
constant time bound then the algorithm will terminate, after visiting all edges and vertices, 
in a finite 0(V + £) time bound. 
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Considering the precedence and indexes of two vertices, u and v, after pre-processing: 



Lemma 5.3.1. u = v <^ u.index = v.index 



Proof 5.3.2. This follows directly from lines 15-16 of listing 5.3.1: 

• Each vertex has a singular numerical index since each vertex is assigned an index when an 
incident edge is processed and that vertex is found to be unvisited; the process of assigning 
the vertex an index means that it is are not unvisited and cannot be subsequently assigned 
another index; and 

• No two vertices can have the same index since the global counter used to assign indexes 
is incremented with each assignment. 

Therefore, each vertex has a unique index and each index is unique to a vertex, proving this 
lemma. □ 
Lemma 5.3.3. If vertex u is contained in the path of tree edges from the root vertex to (the 
distinct) vertex v then the index assigned by the DFS algorithm to u is less than the index 
assigned to v (u -< v u.index < v.index). 



Proof 5.3.4. When an edge is designated as a tree edge it connects from the visited vertex 
u (which is already assigned an index value) to an unvisited vertex v, which is not assigned an 
index value but is then immediately assigned (line 16) a value higher than the previous highest 
index value assigned an index value so u.index < v.index. By definition 3.1.1, given a tree edge 
(u v) then u -< v; therefore, for any tree edge (u v) then u -< v and u.index < v.index. 

Applying this recursively, then sequence of vertices (r, Vi,v 2l ■ ■ ■ ,v n _i,v n ) connected by tree 
edges ((r vi) , («i v 2 ) , . . . , (v n -i v n )) is such that r ~< v\ -< v 2 -< ■ . ■ -< v n -i -< v n and 
that r. index < v\. index < v 2 .index < . . . < v n -\.index < v n .index. 

Therefore, if u -< v then u.index < v.index. □ 

I. , 



This result is particularly useful as provided that whenever vertices are compared they are not 
in different branches of the Tremaux Tree then their relative precedence can be determined by 
a numerical comparison of their associated indexes. Considering the results of chapter 4 then: 



• Each edge connects two comparable (_L) vertices u and v so, by comparing the assigned 
numeric indexes, the relative precedence (or equality) can be determined; 

• Each segment is a chain of edges such that each of its vertices is comparable with each 
other of its vertices - thus the segment's head and tail vertices are comparable so their 
numerical indexes can be used to determine relative precedence and the segment's class; 

• Each non-root segment's head and tail vertices (and the second low-point vertex of that 
segment's head edge) are comparable to that segment's parent's head vertex (and, if the 
parent is of Class 3 or 4, tail vertex) - thus whether a Class 4 segment is flippable or 
not can be determined by the relative precedence of the indexes corresponding to those 
vertices; and 

• The < s precedence order is such that given two segments si and s 2 where s\ < s s 2 and 
si is a sibling of, or sibling's descendant of, s 2 then v\ =<! v\ and that v\ is comparable to 
v\ and i£. By comparing the relative precedence of v\, v\ and v\ then a determination 
can be made as to whether s\ is fully embedded, conflicts or is outside of (and permits 
an embedding) relative to s 2 ; therefore, this determination can be, equivalently, made by 
comparing the indexes associated with those vertices. 



Therefore, vertices' indexes can be used in later phases of the planarity test to determine a 
segment's status and its conflicts with other segments; so the process of determining relative 
precedence between two comparable precedence vertices can be achieved in O(l) time. 
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Listing 5.3 updates each vertex's first and second low-points and propagates these from the 
leaves to the root vertex as the algorithm backtracks and is functionally identical to the snippet 
of Hopcroft and Tarjan's algorithm presented in [32, Pg. 555]. 

> > 

procedure UpdateLowPoints ( e ) { 
let u = e . DFSFrom 
let v = e . DFSTo 
if ( e. status = COTREE ) { 
IP ( v -< u.lowPointl ) 

u.lowPointl «— v 
elseif ( u.lowPointl -4 v -4 u.lowPoint2 ) 
u.lowPoint2 <— v 
} elseif ( e. status = tree ) { 

if ( v.lowPointl -< u.lowPointl ) { 
if ( v.lowPoint2 H u.lowPointl ) 
u.lowPoint2 <— v.lowPoint2 

ELSE 

u.lowPoint2 <— u.lowPointl 
u.lowPointl «— v.lowPointl 
} elseif ( v.lowPointl = u.lowPointl ) { 
if ( v.lowPoint2 -< u.lowPoint2 ) 
u.lowPoint2 <— v.lowPoint2 
} elseif ( v.lowPointl -< u.lowPoint2 ) 
u.lowPoint2 <— v.lowPointl 

} 

} 



Given lemmas 5.3.1 & 5.3.3 then UpdateLowPoints can be implemented by comparing the 
numerical indexes for each vertex in question and therefore, as a series of simple comparisons 
and assignments, can be executed in a constant time bound. 

Listing 5.3 orders the edges by -<* such that if two edges outbound from a common vertex have 
incomparable (||*) precedence they are assigned to the same bucket and their order within the 
bucket is given by the order they are processed by the DFS algorithm. This procedure is the 
same as the function <j> used by Hopcroft and Tarjan [32, Pg. 556]. 

61 procedure AssignEdgeToB ucke t ( e ) { 

62 IF ( e. Status = COTREE ) 

63 append e to tail of bucket ( 2 X e .DFSTo. index — 1 ) 

64 elseif ( e .DFSTo. lowPoint2 -< e. DFSFrom ) 

65 append e to tail of bucket ( 2 X e . DFSTo . lowPoint 1 . index ) 

66 ELSE 

67 append e to tail of bucket ( 2 X e .DFSTo. lowPointl . index — 1 ) 

68 } 



Each bucket is a list and since elements can be appended to a list in constant time (and the rest 
of the procedure is simple comparisons and calculations) then the procedure can be executed in 
a constant time bound. 

Therefore, since these two procedures can be executed in constant time and the DFS portion of 
this phase executes in an 0(V + £) time bound if they are constant then the DFS search has a 
linear time bound. 

Considering the bucket sort, there are 0(V) buckets that must each be checked and, in total, 
each edge is added to exactly one bucket so there will be O(c) to be iterated through; therefore, 
the bucket sort also has an 0(V + £) time bound and so does this entire phase of the algorithm. 
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5.4 Segment Generation Algorithm 



The segment class requires an extra attribute in each of the vertex and edge classes to store a 
reference to the segment containing that element. 



class Vertex { 

attribute segment <— null 

} 



class Edge { 

attribute segment <— null 

} 



The segment class is a list of alternating vertices and edges (although it is possible to define a 
segment purely as a list of edges and obtain the connected vertices as required) associated with 
a lists of child segments for each Class of segment. 

A global list of segments is maintained to store the segments in the order they are generated in 
(which corresponds to the < s order). Whenever a new segment is created it is automatically 
added to the global list by the segment's constructor (this assumes that only multiple planarity 
tests are not performed concurrently) and to the appropriate list within its parent based on that 
segment's class. 

' •> 

global SegmentList = empty list 
class Segment { 

ATTRIBUTE path <— EMPTY LIST 

attribute c 1 a s s 1 c h i 1 d r e n «— empty list 

attribute c 1 a s s 2 c h i 1 d r e n <— empty list 

attribute c 1 a s s 3 c h i 1 d r e n <— empty list 

attribute c 1 a s s 4 c h i 1 d r e n <— empty list 

constructor Segment ( x ) { 

this, path •(— list containing x 
x . segment <— this 
if ( getParentQ null ) { 



28 
29 
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33 



SWITCH 
CASE 1 
CASE 2 
CASE 3 
CASE 4 



( getSegmentClass ( ) ) { 

append this to getParentQ 
append this to getParentQ 
append this to getParentQ 
append this to getParentQ 



classlchildren . 
class2children . 
class3children . 
class4children 



BREAK 
BREAK 
BREAK 



} 

append this to tail of SegmentList 



} 



method addElement ( x ) { 

assert( this . canBeExtendedBy ( x ) ) 

APPEND X TO TAIL OF this. path 

x . segment «— this 



} 

method getHead Q 
method g e t T a i 1 ( ) 



{ return this . path . getHead } 
{ return this . path . getTail } 



method getHeadEdge ( ) { 

if ( getHead Q is edge ) 

ELSE 

} 

method getTailEdge ( ) { 

if ( getTailQ is edge ) 

ELSE 

} 



return getHead 

return getHead ( ) . outbound . getHead ( ) 



return getTailQ 
return getTail Q. parent 
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method getHeadVertex Q { 

if ( getHeadQ is vertex ) return getHeadQ 
else return get Head (). DFSFrom 

54 } 

method getTailVertex Q { 

ip ( getTailQ is vertex ) return getTailQ 
else return getTailQ .DFSTo 

} 

method get Segment Class ( ) { 

if ( g e t T a i 1 ( ) is vertex ) return 1 

else if ( getHeadVertex ( ) -< getTailVertex ) return 2 
else if ( getHeadVertex ( ) = getTailVertex ) return 3 

ELSE RETURN 4 

} 

method getParentQ { 

if ( getHeadQ is vertex ) return null 

else return getHead (). DFSFrom . segment 



method canBeExtendedBy ( x ) { 

if ( x is edge ) return ( getTailQ = x. DFSFrom ) 

else return ( getTailQ is tree edge and getTailQ .DFSTo = x ) 



92 

93 
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The procedure to generate segments performs a simple DFS over the outbound edges (which 
are in <** order from the bucket sort) from each vertex; as each edge is considered by the DFS 
it either extends the existing segment's path (and so is added to that path) or is the head of 
a new segment. The segments are stored in the global list, as previously mentioned; as well as 
being accessible via the segment attribute of each vertex and edge and from other segments via 
the parent-child hierarchy. 

^ Listing 5.4.1: Segment Generation Algorithm 

procedure GenerateSegments ( root ) { 

LET E = EMPTY STACK 

let s = new Segment ( root ) 

for each ( e e root . outbound [in reverse order] ) 
PUSH e ONTO E 

WHILE ( E IS NOT EMPTY ) { 
POP e FROM E 

if ( s = null ) let s = new Segment ( e ) 
else s . addElement ( e ) 

if ( e. status = cotree ) { 

LET S = NULL 
} ELSE { 

let v = e . DFSTo 
s . addElement ( v ) 
if ( v. outbound is empty ) 

LET S = NULL 
ELSE 

for each ( e' 6 v. outbound [in reverse order] ) 

PUSH e 1 ONTO E 



100 
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} 
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When a given vertex is processed then its outbound edges are added to the top of the stack 
in reverse order (such that the maximum <** outbound edge is added first and the minimum 
<** outbound edge is added last and is on the top of the stack); thus when the next edge is 
processed (from the top of the stack) it will be the minimum <** precedence edge outbound 
from the last vertex and will correctly extend the segment containing that given vertex. The 
algorithm can then check to see if a leaf has been reached (i.e. a cotree edge or a vertex with no 
outbound edges) and if so sets the current segment to null indicating that when the next edge (if 
any) is processed then the algorithm will have backtracked and be starting a new segment (with 
the next minimum <** precedence outbound edge from the most recent, highest -< precedence, 
vertex still with unprocessed outbound edges). Therefore, not only does the algorithm generate 
the segments simply; it also generates them in < s order. 

Since each edge is only outbound from one vertex then each edge is added to stack E once so 
can only be removed from E once and added to a segment once. Similarly, each vertex is added 
to a segment if it is the root vertex or when its parent tree edge is processed and so each vertex 
is only processed once and added to a a single segment. Given this then segment generation is 
0(V + £) 

Listing 5.4.1 is very similar to the pathfinder procedure of Hopcroft and Tarjan [32, Pg. 556] - 
the fundamental difference is that where H&T assume a biconnected graph they can also assume 
that every segment is terminated by a cotree edge and as soon as a cotree edge is found the old 
segment can be closed and a new one started. This algorithm also handles the case of Class 1 
segments where the segment's tail is a vertex with no outbound edges. 
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5.5 Planarity Testing and Permutation Generation Algo- 
rithm 

Prior to the implementation of the planarity test, some useful attributes and methods can be 
added to the segment class. 

• The lastEmbeddedSegment attribute is a reference to the most recently embedded child 
segment of this parent and is used to determine whether the currently embedded segment 
(also a child of this parent) is permutable with that most recently embedded child (its 
sibling) . 

• The blocks attribute is simply that - a stack of blocks which are relative to this segment. 
It is used as a temporary holder for blocks during embedding such that when all of a 
segments descendants are embedded the method appendDescendantSegmentsToParent 
can be invoked and all blocks of partially embedded segments can then be fully embedded 
if they are on the outside (and ignored) or else, if on the inside, appended to the block 
containing this segment's parent. 

• The permutation attribute is a reference to a permutable group of segments - initially, the 
segment does not belong to any such group but may be assigned to one if, when compared 
to the lastEmbeddedSegment of its parent it is found to be permutable. 

• The embedded attribute is a boolean flag indicating whether the segment was successfully 
embedded or not. 

Listing 5.5.1: Extending the Segment Class 

class Segment { 



attribute lastEmbeddedSegment <— null 

ATTRIBUTE blocks <— EMPTY STACK 

attribute permutation <— null 

attribute embedded <— false 

method getLowPointl () { 

if ( getHeadQ is vertex ) return getHeadQ ; 

if ( getHead (). status = cotree ) return getHeadVertex ( ) 

return min( getHead () .DFSTo. lowPointl , getHeadVertex ( ) ) 

} 

method getLowPoint2 ( ) { 

if ( getHeadQ is vertex ) return getHeadQ; 

if ( getHead Q. status = cotree ) return getHead Vertex ( ) 

return min( getHead Q. DFSTo . lowPoint2 , getHeadVertex ( ) ) 

} 

method hasBridgeEdges ( ) { return getSegmentClass < 2 } 

method isRotatable () { return not isStatic{} and getSegmentClass < 3 } 

method isReversible () { return not getParent Q = null and 2 < 

getSegmentClass < 3 } 

METHOD i s S t a t i c ( ) { 

return ( getParent Q = null ) 

OR ( getParent Q . getParent Q = null and this = 
get Parent (). childr en . getHead ( ) ) 

} 

method isFlippableQ { 
return not i s S t a t i c ( ) 

and getSegmentClass ( ) = 4 

and ( ( getParent (). getHeadVertex ( ) ^ getTailVertex ( ) ) 
or ( getParent Q . getTailVertex = getTailVertex ( ) 
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and get Parent (). getHead Vertex ( ) =^ getLowPoint2Vertex ( ) ) ) 

} 

method conflictsWith( s ) { 

return ( s . getTailVertex ( ) -< t h i s . get Tail Vert ex ( ) 

-< s . getHeadVertex ( ) -< t h i s . get Head Vertex ( ) ) 
or ( this . getTailVertex () -< s . get Tail Vert ex ( ) 

H this . getHeadVertex ( ) -< s . getHeadVertex ( ) ) 

} 

method appendDescendantSegmentsToParent ( ) { 
if ( getParentQ = null ) return 
let tempSegmentList = empty list 
while ( not blocks . isEmpty ( ) ) { 

REMOVE b PROM TAIL OP blocks 

I F ( not b.isFlippableQ ) 

move all from b . p a r t i a 1 1 n s i d e to head of tempSegmentList 

} 

getParent () . blocks . getTail () . appendSegments After ( this , tempSegmentList ) 

} 



Considering the time complexity of the methods added to the the segment class: 



• The method appendDescendantSegmentsToParent iterates through every block contain- 
ing non-flippable partially embedded descendants (relative to that segment) on its inside 
and moves them out of those blocks and into the block containing this segment (and on the 
same side as this segment). It performs this operation by moving the partially embedded 
contents of the block to a temporary list (so as to preserve their order) and then moving 
the entire temporary list to the parent block. Each movement of the list can be performed 
by disconnecting the list elements from its containing data structure and connecting it 
into the new list such that only the head and tail of the list needs considering and so can 
be performed in a constant time bound. 

If there are b blocks of non-flippable partially embedded segments then each block is removed 
from the list of blocks once and can be added to the temporary list, at most, once which 
all takes 0(b) time; the temporary list can then be appended to the parent's block which 
takes O(l) time. Therefore, the method takes 0(b) time. 

• All the other methods perform simple comparisons and execute in a constant time bound. 
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A block contains four lists: the partially embedded segments inside and outside of the block; and 
a list of all segments (partially or fully embedded) that have been added directly to that block 
(not indirectly when moved from a descendant). 

It also contains attributes which are: 

• A reference to the previous block on the same parent (forming a singly linked list) that is 
used when concatenating blocks; 

• A reference to the parent segment that the block is relative to; and 

• A boolean flag containing the status as to whether all segments of the block (partially or 
fully embedded) are flippable - if so then the block is flippable. 

Most of the methods are self explanatory, however: 

• f ullyEmbedTo takes a vertex as an argument and checks the partially embedded segments 
to see if, relative to that vertex, they are now fully embedded and have no further influence 
on future segment's embeddings. Each time a segment is found it is removed from the list 
of partially embedded segments; the method returns true if all the block's segments are 
fully embedded and false if there exists at least one partially embedded segment. 

If there are x segments currently with the status partially embedded that change to fully 
embedded then the method has a 0(x) upper time bound. 

• The concatenate method coalesces the block with its immediate predecessor; this can be 
achieved in a constant time bound by manipulating the references to the head and tail of 
the list rather than iterating over the entire list. 

• All other methods are self explanatory and execute in a constant upper time bound. 

Listing 5.5.2: Block Class 



GLOBAL BlockList = EMPTY LIST 

class Block { 

attribute p a r t i a 1 1 n s i d e <— empty list 

attribute p a r t i a 1 u t s i d e <— empty list 

attribute alllnside <— empty list 

attribute allOutside 4— empty list 

attribute previous 

attribute parent 

attribute flippable 

CONSTRUCTOR Block( S ) { 

append s to tail of t h i s . p a r t i a 1 1 n s i d e 
append s to tail of this.alllnside 
this. parent 4— s . getParent ( ) 

t h i s . pre vious 4— parent . blocks . get T ail ( ) 

t h i s . f 1 i p p ab 1 e +— s . i s F 1 i p p ab le ( ) 

t h i s . parent . lastEmbeddedSegment 4— s 
append this to tail of p ar e n t . b 1 o c k s 
append this to tail of BlockList 

} 

method addSegmentlnside ( s ) { 

append s to tail of t h i s . p a r t i a 1 1 n s i d e 
append s to tail of this . alllnside 

82 if ( t h i s . f 1 i p p ab le ) t h i s . f 1 i p p a b le = s . is F lipp able ( ) 

83 this . parent . lastEmbeddedSegment = s 
} 

method addSegmentOutside ( s ) { 

87 append s to tail of t h i s . p a r t i a 1 u t s i d e 

88 append s to tail of this . allOutside 
t h i s . parent . lastEmbeddedSegment = s 

} 
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method appendSegmentsAfter ( s, SList ) { 
if ( t h i s . p ar t i a 1 1 ns i d e . get T ai 1 ( ) = s ) 

append SList to tail of t h i s . p a r t i a 1 1 n s i d e 
else append SList to tail op this . p ar t i a 1 u t s i d e 

} 



method fullyEmbedTo ( v ) { 

99 while ( not t h i s . p a r t i a 1 1 n s i d e . isEmpt y ( ) 

100 and v =^ t h i s . p ar t i a II ns i d e . get T ail ( ) . get Tail Vert ex ( ) ) 

101 remove tail from t h i s . p a r t i a 1 1 n s i d e 

102 while ( not t h i s . p a r t i a 1 u t s i d e . isEmpt y ( ) 

103 and v =<! t h i s . par t ialO ut si de . ge t T ail ( ) . get Tail Vert ex ( ) ) 

104 remove tail from t h i s . p a r t i a 1 u t s i d e 

105 return ( t h i s . p ar t i a 1 1 n s id e . isEmpty ( ) and t h i s . p art i al O ut side . isEmpty ( ) ) 

106 } 

108 method conflictInsideWith( s ) { 

109 return not t h i s . p a r t i a 1 1 n s i d e . isEmpty ( ) 

no and t his . p a rt i al I ns i de . get Tail (). conflict s Wit h ( s ) 
} 

u.i method conflictOutsideWith( s ) { 

114 return not t h i s . p a r t i a 1 u t s i d e . isEmpt y ( ) 

115 and this.partialOutside.getTail().conflictsWith( s ) 

116 } 



11S 
119 
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method concatenate ( ) { 

t h i s . pre vious . f li p p ab 1 e <— ( t h i s . pre vious . f 1 i p p ab 1 e and this 
move all from this . p a r t i a 1 1 n s i d e to tail of this . previous 
move all from this . p a r t i a 1 u t s i d e to tail of this . previous 
move all from this . alllnside to tail of this . previous 

move all from this . allOutside to tail of this . previous 



} 



remove this from tail of t h i s . p ar e n t . b 1 o c k s 



flippable ) 

partiallnside 

partialOutside 

alllnside 

allOutside 
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METHOD f 1 i p ( ) { 

swap partiallnside 
swap alllnside 

} 



and partialOutside 
and allOutside 
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The procedure checkEmbedding is used to check a segment and a block to see if they are 
compatible for an embedding. Given that the segment can be tested against the inside and 
outside of the block for a conflict in a constant time and the rest of the method is simple 
comparisons then the procedure has an O(l) upper time bound. 

There are six possible outcomes: 



1. When the segment conflicts with both sides of the block and is non-planar; 

2. When the segment conflicts with neither side of the block and so can form a new block 
inside the previous; 

3. When the segment does not conflict with the inside of the block but does conflict with the 
outside - so can, potentially, be embedded directly onto the inside of the block; 

4. When the segment conflicts on the inside but not the outside and the segment is flippable 
- so can, potentially, be embedded directly onto the outside of the block; 

5. When the segment conflicts on the inside but not the outside and the segment is not 
flippable but the block is - then the block must be flipped for an embedding to occur; and 

6. When the segment conflicts on the inside but neither segment nor block can be flipped and 
so the graph is non-planar. 
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procedure checkEmbedding ( segment, block ) { 

let inConflict = block . conflictlnsideWith ( segment ) 
let outConflict = block . conflictOutsideWith ( segment ) 



IF 
IF 
IF 
IF 
IF 



inConflict and outConflict ) return CONFLICT_ON_BOTH_SIDES 

not inConflict and not outConflict ) return NEW_BLOCK 
not inConflict ) return EMBED_INSrDE 

segment . isFlippable () ) return EMBED_OUTSIDE 

block . isFlippable () ) return FLIP_EMBED_INSIDE 

return CONFLICT INSIDE 
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Below is the planarity testing algorithm. It uses a DFS over the segment hierarchy - on the 
forward search (lines 162-242) the algorithm tests each segment against the most recent block(s) 
relative to its parent and on the backtracking phase (lines 244-245) it propagates the partially 
embedded descendant segments from their current block to the parent block. 
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procedure AddChildrenToStack ( segment 




s ) { 
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) 
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PUSH S 
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REVERSE 
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} 
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procedure TestPlanarity ( rootVertex ) 


{ 
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let lastSe 


gmentProcessed <— null 
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LET S -f— EMPTY STACK 
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AddChildrenToStack ( root Vertex . segment , S ) 

WHILE ( S IS NOT EMPTY ) { 
PEEK AT S ON S 

if ( not s . embedded ) { 

if ( s . get Segment Class ( ) = 4 ) { 
let p <— s . parent 
let b <— p . blocks . getTail () 
let 1 <— p . lastEmbeddedSegment 

IF ( S AND 1 ARE PERMUTABLE ) { 

if ( 1 . permutation is not null ) { 

append s to tail of 1 . permutation 

s . permutation 4— 1 . permutation 
} ELSE 

s . permutation •<— 1 . permutation <— list containing 1 and s 
b . appendSegments After ( 1 , s ) 
p . lastEmbeddedSegment <— s 

} ELSE { 

WHILE ( b IS NOT NULL ) { 

if ( not b . fullyEmbedTo ( s . getHeadVertex ( ) ) ) 

BREAK 

s . blocks . removeTail () 
b p. blocks . getTail ( ) 

} 

IF ( b IS NULL ) { 

new Block( S ) 

} ELSE { 

let side <- INSIDE 

LET EMPTY -f— FALSE 
let done <— FALSE 

switch ( checkEmbedding ( 
case CONFLICT_BOTH_SIDES : 
case CONFLICT_INSIDE : 
case NEW BLOCK: 



case EMBED OUTSIDE: 



case FLIP_EMBED_INSIDE: 
case EMBED_INSIDE: 
} 

WHILE ( EMPTY AND b. previous IS NOT NULL ) { 



b ) ) { 
return NON_PLANAR 
return NON_PLANAR 
new Block ( s ) 

CONTINUE 

side <- OUTSIDE 

empty «— b . isEmptyOutside ( ) 

CONTINUE 

b. flip () ; 

empty •(— b . isEmptylnside ( ) 
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} 



} 



EMPTY <— FALSE 

let pside -f- INSIDE 
switch ( checkEmbedding ( s. 
case CONFLICT_BOTH_SIDES: 
case CONFLICT_INSIDE: 
case NEW BLOCK: 



case EMBED OUTSIDE: 



case FLIP_EMBED_INSIDE: 
case EMBED_INSIDE : 
b. previous . isEmptylnside () 
} 

if ( not done ) { 

if ( pside 5^ side ) { 

if ( b . pre vious . i s F 1 i p p ab 1 e ( ) ) 

b. previous, flip () 
else if ( b . isFlippable () ) { 
b. flip () 
side <— pside 
} ELSE 

return NON_PLANAR 

} 

b. concatenate () 
b <— b . previous 

} 

} 

if ( not done ) { 

if ( side = INSIDE ) 

b . addSegmentlnside ( s ) 

ELSE 

b . addSegmentOutside ( s ) 

} 



b . previous ) ) { 
return NON_PLANAR 
return NON_PLANAR 
if ( side = INSIDE ) 

b . addSegmentlnside ( s ) 

ELSE 

b . addSegmentOutside ( s ) 
done = true 

CONTINUE 

pside «- OUTSIDE 

EMPTY <— 

b . previous . isEmptyOutside () 

CONTINUE 

b. previous . flip () ; 

EMPTY <— 



AddChildrenToStack( s, S ) 
s . embedded <— true 
} else { 

s . appendDescendantSegmentsToParent () 

POP S FROM S 

} 



Looking at the algorithm in more depth: 



• Lines 167-174 consider when a segment s and its preceding sibling I are permutable; which 
occurs when vf = v\ and v s h — vf 2 = v l h — v\ 2 . 

In this case, the new segment and the old are added to a permutable group - this can 
initially be considered to be a linked list structure for its ability to be populated in an 
upper time bound equal to the number of elements added to the list (without knowing 
the size of the group previously). Thus p permutable segments can be embedded in O(p) 
time. 

• Lines 176-181 consider whether the partially embedded segments are fully embedded. If 
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they are then they are removed from the block and if the block is emptied then it too is 
removed; thus leaving the stack of blocks either with only partially embedded segments or 
empty. 

The time complexity of this part is considered later with the concatenation of blocks. 

• Line 184 is reached either by the first child segment or when all previous siblings and their 
descendants have been fully embedded - in this case the segment has a trivial embedding 
inside its parent and forms a new block. 

This can be achieved in a constant upper time bound. 

• Lines 186-199 tests the segment for an embedding against the last block. Since it is 
constant upper time bound to check the status of a segment's embedding with a block 
and to flip blocks and add segments to blocks then this portion of the algorithm can be 
performed in constant time. 

• Lines 201-217 performs a similar test on the penultimate block. Again requiring a constant 
upper time bound for this portion. 

• However, considering the entire while loop (lines 200-230) then the result of one iteration 
is that either: 

— The case NEW_BLOCK is reached and the segment is added to the last block without 
affecting the penultimate block and the loop terminates; 

— A NON_PLANARITY case is reached and the entire procedure terminates; or 

— The last and penultimate blocks are concatenated. 

In the first two cases the algorithm breaks out of the loop and can perform all actions 
within that iteration of the loop in constant time. In the last case, the algorithm iterates 
through the loop and performs a concatenation between the last and penultimate blocks 
- this is achieved in constant time bound but if the both the last and penultimate blocks 
are empty on the side in which the segment is being embedded then the loop can iterate 
again and a new penultimate block can be considered. 

Considering the algorithm in totality, then the individual portions of the algorithm have constant 
execution time within a single iteration with the exception of: looping to remove fully embedded 
segments and empty blocks; looping to concatenate blocks; and looping during backtracking to 
move segments to a parent block (and discard the child blocks). 

In all these cases either: a segment changes status from partially to fully embedded; and/or 
a block is discarded. Since each segment can only have this status change once and that each 
block can only be emptied and discarded once then this may occur multiple times within a single 
iteration but there is a finite number of times it can occur over all iteration - such that at most 
there can be O(S) times at which a segment is removed from a block and 0(§) times a block 
can be deleted. 

Therefore, if there are § segments then each iteration takes a constant time plus there is 
additional O(S) time spread across all iterations so the total execution time for the planarity 
test is 0(B). 

Each segment is partially embedded within a single block and can only be fully embedded 
once, removing it from that block. This occurs either when testing a subsequent segment for 
embedding or during backtracking but can only occur in one of these cases for each segment. 

Similarly, each block can only be formed once and can be discarded if either: all segments within 
it are fully embedded or if it is concatenated with a previous block. 
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5.6 Reordering Permutations 

5.6.1 Steinhaus- Johnson-Trotter Permutation Algorithm 

The Steinhaus-Johnson- Trotter algorithm is a method of generating permutations such that 
" each permutation is derived from its predecessor by the interchange of two marks in adjacent 
positions. Moreover, the rules are extremely simple" [38, pg. 282]. 

The algorithm was originally discovered by Hugo Steinhaus (Summarised in [40, Section 3.4]) 
and rediscovered independently by many others including Trotter [76] and Johnson [38] . 

The algorithm is summarised below: 

• The elements of the input sequence are each assigned an index (a unique sequential value) 
of ascending value corresponding to the element's position in the sequence (lowest index 
at the head of the list) ; 

• Elements are given a direction of travel; initially towards the head of the sequence; 

• Elements are mobile if, in their direction of travel, they are not at the end of the list or 
the adjacent element has a higher index; 

• At each stage, the mobile element with the highest index is swapped with the adjacent 
element in its current direction of travel and the direction of travel is reversed for all 
(immobile) elements with a higher index 

• The result of that stage is a new permutation which differs from the permutation at the 
previous stage by the transposition of a pair of adjacent elements. 

This algorithm follows a predictable iterative pattern for a sequence of size N: 

• The largest indexed element is moved from the tail-to-head of the sequence in (N — 1) 
swaps; 

• On the N th swap the element with the largest index is immobile at the head of the sequence 
and the sub-sequence of lower indexed elements is considered and one step of the algorithm 
is performed on this sub-sequence, moving the next highest indexed mobile element; 

• On the (N + l) th to (2N — l) th swaps the largest element is moved head-to-tail of the 
sequence; 

• On the 2N th swap, when the element with the largest index is immobile at the tail of 
the sequence, again the sub-sequence is considered and the next highest indexed mobile 
element is moved; 

• This process is repeated, in batches of 2N swaps, until all permutations of the sub-sequence 
of lower indexed elements has been cycled through (in N\ steps). 

• When the algorithm terminates no elements will be mobile (element 2 will be at the head 
of the sequence followed by element 1, both of which will have direction towards the head, 
and elements 3 to N will be in that order and have direction towards the tail) and the 
algorithm can be reset by swapping the lowest and second lowest indexed elements and 
resetting the element's direction of travel to be towards the head. 
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(a) (b) (c) (d) 

Figure 5.6.1: Graphical Representation of Steinhaus- Johnson- Trotter Permutation Algorithm 
for One (a) to Four (d) Elements Showing how the Pattern of Permutations Generated Builds 
on the Previous. 



Figure 5.6.1 shows the sequential swaps performed by the algorithm for sets of size one (a) 
through four (d). Each permutation is a vertical group of elements with: the initial state on 
the left; the terminating state (where no elements are mobile) as the penultimate vertical group 
on the right; and the swap (dashed lines) required to reset the sequence's order on the right. 
It illustrates the relationship between (previous) permutations of a set of elements and (next) 
permutations for that set with an additional element such that successive sub-figures show the 
movement of that additional clement and when that additional element reaches an outermost 
position the next swap of the previous permutation is performed. 

Simplified Steinhaus-Johnson- Trotter Permutation Algorithm 

As previously noted, the Steinhaus-Johnson-Trotter algorithm follows a repeating pattern of 
transpositions for the highest indexed element and this pattern can be iteratively applied to 
the sub-sequence of lower indexed elements. As a result the element and swap direction can be 
calculated: 

• For a set with N elements, when cycling through permutations, the largest (A th ) indexed 
element (initially at the tail of the order) will be moved when the number (C) of swaps, 
from the initial order, (designated as the Current Permutation Index) is not exactly 
divisible by N (i.e. modulo(C, N) ^ 0) and the direction of travel will be towards the 
head of the sequence if (modulo(C, 2N) < N) or towards the tail otherwise. Therefore, 
for out of every N steps (or (Nl — (N — 1)!) out of N\ total permutations) the element 
with the largest indexed element will be moved. 

• The element with the second largest index will move when (modulo(C, N) = 0) 
and (modulo(j^,N — 1) ^ 0) and the direction of travel is towards the head when 
(modulo(jj ,2(N — 1)) < (N — 1)) or towards the tail otherwise. Therefore for every 
(N - 2) out of N(N - 1) steps (or ((JV - 1)! - (JV - 2)!) out of Nl total permutations) the 
second largest indexed element will be moved. 

• In general, the K th indexed element of an N element set will move if C is exactly divisible 
by (jjt) but is not exactly divisible by K and its direction of travel is towards the head if 
(modulo(C j^j , 2K) < K) or towards the tail otherwise. The K th element will be swapped 
(Kl — (K — 1)!) out of AH total permutations. 

Given this general formula and the current permutation index for the permutation it is possible 
to calculate which element will be moved and its direction of travel. Testing the elements 
of the sequence to locate the position of the highest indexed mobile element has an O(N) 
upper time bound (where N is the number of elements in the sequence). This time bound 
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is identical to the time bound when testing the mobility of element of successively decreasing 
indexes against their neighbour in their direction of travel; however, there is no requirement 
to store the direction of travel as this can be calculated at the same time as the index of the 
highest mobile element is found nor is there a requirement to update the direction of travel 
after performing a transposition. It also allows for a simple algorithm to jump to a specific 
permutation index (see sub-section 5.6.1 on page 95). 

The following describes the data structures required: 



permutation : (X) 



element Index : N — » N 



• elementPosition : N — >• N 



current Permutation : N 



total Permutations : N 



A permutable sequence (in this case, the elements contained are 
segments) provided as input with a static order. This is assumed 
to be pre-generated prior to initialising indexes and performing 
transpositions. 

A mapping from the index of an element within the original 
sequence to the current position of that element within the 
current permutation. 

A mapping from the current position of an element to the index 
of that element. This is the inverse mapping of elementlndex 
and is used to reference adjacent elements during transposition. 

The current permutation index (how many transpositions since 
the original). 

The total number of permutations for the sequence; a constant 
value equal to the factorial of the size of the permutable 
sequence. 



The input permutation is assumed to be pre-generated but the other data can be initialised as 
follows: 

currentPermutation 4— 
totalPermutations 4— 1 
for ( i <— 1 ... | permutation | ) { 

elementlndex ( i ) 4— i 

elementPosition ( i ) 4— i 

totalPermutations «— totalPermutations X i 

} 



A simple procedure is required to swap the position of two adjacent elements and takes two 
arguments: the index of the current mobile element and a boolean flag for the direction of travel 
(true indicates towards the head and false towards the tail). 

/ \ 

procedure swapElement ( mobileElement , direction ) { 
mobilePosition <— elementPosition ( mobileElement ) 
IP ( direction ) swapPosition <— mobilePosition — 1 
else swapPosition <— mobilePosition + 1 

swapElement 4— elementlndex ( swapPosition ) 
elementPosition ( mobileElement ) +— swapPosition 
elementPosition ( swapElement ) 4— mobilePosition 
elementlndex ( mobilePosition ) <— swapElement 
elementlndex ( swapPosition ) 4— mobileElement 



The result is that the element indexes at adjacent positions are swapped and the element 
positions of those indexes are swapped. 
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The procedure to step from one permutation to the next is: 

r 

procedure nextPermutation ( ) { 

p 4— currentPermutation <— modulo ( currentPermutation + 1, totalPermutations ) 
for ( to •<— | permutation | ... 2 ) { 
if ( modulo ( p, m ) ^ ) { 

if ( modulo ( p, 2xm)<m) swapElement ( m, true ) 
else swapElement ( m, false ) 

RETURN 

} 

p <— p -i- m 

} 

swapElement ( 1 , true ) 
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Time Complexity of Steinhaus-Johnson- Trotter Algorithm 

Looking at the performance of the algorithm: 

• The initial population of the element and position arrays and calculation of the total 
number of permutations can be performed in O(N) time. 

• The function to swap elements can be performed in 0(1) time. 

• There are N\ permutations in total. 

• (AH — (N — 1)!) of the permutations are generated by swapping the largest (iV th ) element; 
requiring a single iteration of the loop within the next permutation function. 

• Of the (N — 1)! remaining permutations, ((N — 1)! — (N — 2)!) are generated by swapping 
the second largest element; requiring an iteration to determine that the largest element 
is immobile and a second iteration to determine the second largest element is mobile and 
swap it. 

• In general, the K th element is swapped (K\ — (K— 1)!) times during an entire cycle through 
all permutations. Moving that element requires N — K iterations through the loop to check 
that the elements iV through K + 1 are immobile and then one final iteration to swap the 
K th element. 

• When all elements are immobile then the 1 st element is swapped; the loop is iterated over 
(N — 1) times, checking that the N th down to 2 nd elements are immobile before the 1 st 
element is swapped (once the previous elements are all immobile there is no requirement 
to check for mobility of the 1 st element as there is only one permutation where this occurs, 
and will reset the order). 

• For an N element sequence, to cycle through all possible (AT) permutations requires a 
total of J2k=2(N — fc + l)(fc! — (fc — 1)!) = J2k=2 iterations through the loop and N\ 
swaps. 

— At N — 3, there are a total of 6 permutations and the loop within the next Permutation 
procedure is iterated over a total of 8 times giving an average cost of 1.3 iterations 
per permutation. 

— At N — 4, there are 24 permutations and 32 iterations, again, giving an average cost 
of 1.3 iterations per permutation. 

— At N — 5, there are 120 permutations and 152 iterations, giving an average cost of 
1.26 iterations per permutation. 

Generally, when N > 2, the average number of iterations over the loop within the next Permutation 
procedure (over all TV! permutations) is given by J2k=2 M an( ^' 38 ^ tends to infinity, the average 
cost tends towards 1. 

The maximum cost for moving from one permutation to the next requires (N — 1) iterations 
through the loop but this only occurs when moving the 2 nd element (on the | A! th permutation) 
and when resetting the permutation order by moving the 1 st element (on the (AH — l) th 
permutation) . 

Therefore, the cost of the Steinhaus-Johnson- Trotter algorithm depends on whether the 
algorithm is considered in the context of: generating a single permutation from the previous 
permutation (1 permutation in maximum of O(N) time); or generating all possible permutations 
(N\ permutations in 0(N\) time). 
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Jumping to a Permutation Index 



The largest (N th ) indexed element starts (0 th permutation) at the tail of the sequence (iV th 
position) and steps towards the head until it reaches the 1 st position in the (N— l) th permutation. 
For the next N permutations: the largest indexed element start in the 1 st position (on the ./V th 
permutation) and step until it reaches the tail-most (iV th ) position on the (2N— l) th permutation. 
This pattern is repeated for blocks of 27V permutations. Therefore the position of the largest 
element can be calculated from the permutation index (C) with the given pseudo code: 

i s 

1 if ( modulo( C, 2 X N ) < N ) position <- N — modulo ( C, N ) 

2 else position <— modulo( C, N ) + 1 

3 elementPosition ( N ) «— position 

4 elementlndex ( position ) <— N 



Considering the second largest indexed element, while ignoring the position of the largest indexed 
element, then on the th permutation it is at the tail of the sequence ({N— l) th position, ignoring 
the largest indexed element) and on the N th permutation it moves one position headwards. This 
is repeated every /V th permutation until the (N(N — 1) — l) th permutation when it is at the 
head of the sequence (still ignoring the position of the largest indexed element). The pattern 
is again repeated moving towards the tail for the next N(N — 1) permutations and then cycles 
until all N\ permutations are achieved. 

The second largest element can be treated in exactly the same fashion as the largest, above, 
with three changes: 



• (N — 1) is substituted in place of N: 

• I is substituted in place of C; and 

• The position of the second largest element ignores the largest element. By calculating 
the position of the largest element prior to the second largest element then if the largest 
element equals or precedes the position of the second largest clement then the second 
largest element's position must be shifted one place towards the tail to account for this. 



This can be extended iteratively to successive sub-sequences of lower indexed elements to give 
a general rule to calculate the position of the permuted elements: 

procedure jumpToPermutation ( C ) { 

ORDER <— ( ) 

FOR ( k <— N . . . 1 ) { 

i <- 1 

m Ar- modulo ( C, k ) 

if ( modulo ( C, 2 X k ) < k ) position-*— k — m 
else position m + 1 

while ( i < | order | and order( i ) < position ) { 

position <— position + 1 

i <- i + 1 

} 

IP ( i < | ORDER | ) 

INSERT position INTO ORDER IMMEDIATELY PRECEDING ORDER( i ) 
ELSE 

APPEND position TO TAIL OF ORDER 

elementPosition ( position ) <— k 
elementlndex ( k ) position 
C «- (C - m) -r k 

} 

} 
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For example, the steps to generate the 23 rd Steinhaus- Johnson- Trotter permutation of the 
sequence (A,B,C,D } E) is shown in Table 5.6.1 (C = 23, iV = 5). The algorithm requires 
5 position assignments and 7 position shifts to generate this permutation. 



k 


q 




mod(q, k) 


mod(q, 2k) < k 


Initial 


Shifts 


Permutation 










Position 






5 


23 


1 120x23 1 
L 120 J 


3 


True 


5-3 = 2 




(,E, , , ) 


4 


4 


1 24x23 1 
~~ L 120 J 





False 


1 




(D,E, , , ) 


3 


1 


1 6x23 1 
L 120 J 


1 


True 


3-1 = 2 


D:2 i y 3 


(D,E, ,C, ) 














E:3 i v 4 




2 





_ 1 2x23 | 
L 120 J 





True 


2-0 = 2 


D:2 i y 3 


(D,E, ,C,B) 












E:3 i v 4 
C:4 i y 5 




1 





1 1x23 1 
L 120 J 





True 


1-0 = 1 


D:l i y 2 


(D,E,A,C,B) 



Table 5.6.1: 23 rd Steinhaus- Johnson- Trotter permutation of the sequence (A 7 B 7 C,D,E). 



The minimum number of position shifts is and occurs on the th permutation (i.e. 
(A, B,C, D, E)), whereas the maximum number of position shifts occurs on the 64 th permu- 
tation, when the permutation is reversed (i.e. (E,D 7 C 7 B 7 A)), and requires 10 position shifts. 

In general, for an N element set, there are N initial position assignments and between and 
7}(N 2 — N) position shifts 1 . This means that the th permutation can be generated in O(N) time 
and memory and a general permutation can be generated in 0(7V 2 ) time and O(N) memory. 

Permutation Constraints 

Constraints can be added to a permutation such that one element must always be before another 
element. Since the only change between one permutation and the next in the sequence is 
swapping a pair of neighbouring elements then it is trivial to store the Boolean validity state 
for each constraint and test if this swap changes the validity of the permutation against each 
constraint; this requires, for K constraints, O(K) memory and time to go from one permutation 
to the next (note: this is bounded by the number of constraints and has no relation to the size 
of the permutation) . 

If a single constraint is required and it can be arranged that the lowest indexed element must 
be leftwards of the second lowest indexed element then: permutations to (4p — 1) will be 
valid permutations; on the ^ th permutation the lowest and second lowest indexed elements are 
swapped, invalidating the constraint, so the second half of the permutations are all invalid; until 
the iV! th transposition when the order is reset. This is a particularly useful result as the valid 
permutations can be cycled through until the first invalid permutation is reached and then a 
jump can be made back to the th permutation in O(N) time (the same time bound as swapping 
the smallest and second smallest indexed elements). Therefore, in this case, the algorithm will 
still be bounded at O(N) maximum and 0(1) mean time per transposition between sequential 
permutations. 

1 When each successively lower indexed element attempts to insert itself into the permutation at position 1 then 
the highest indexed element succeeds, the next highest element is shifted once to the right; the next highest 
element is shifted twice; and so on until the lowest indexed element is shifted right (N — 1) times and is inserted 
into the right-most position. The total number of shifts required to accomplish this is J^^Jq 1 & = \(N 2 — N). 
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Iterating Through All Permutations of a Biconnected Graph 

The procedure below considers the process of iterating through all possible permutations of 
embedding for a biconnected graph. 

^ Listing 5.6.1: Iterating Through All Permutations 

LET / «— NUMBER OF PLIPPABLE BLOCKS 

LET p <— NUMBER OF PERMUTABLE GROUPS OF SEGMENTS 

let FlippableBlocks <— array of all flippable blocks 

let PermutableGroups -f— array of all permutatable groups of segments 
let FlipPermutation <— 
let TotalFlips <- 2? 

procedure nextEmbedding ( ) { 

FlipPermutation <— FlipPermutation + 1 
if ( FlipPermutation > TotalFlips ) { 
FlipPermutation i— 
let i <— 

while ( < i < p ) { 

if ( PermutableGroups [ i ] has more permutations ) { 
PermutableGroups [ i ] . nextPermutation () 
if ( PermutableGroups [ i ] is valid permutation ) { 

i i 1 

} ELSE { 

PermutableGroups [ i ]. jumpToPermutation ( ) 
i «- i + 1 

} 

} ELSE { 

PermutableGroups [ i ]. jumpToPermutation ( ) 
i «- i + 1 

} 

} 

if ( i = p ) 

return ALL_EMBEDDINGS_FOUND 

} 

LET k = 1 ; 

FOR ( b = ... f-1 ) { 

if ( BITAND( FlipPermutation , k ) > ) { 

FlippableBlock [b] is flipped 
} else { 

FlippableBlock [b] is not flipped 

} 

k <- k X 2 

} 

return NEXT_EMBEDDlNG_FOuND 

} 



Considering the time bound of this procedure then, at worst, a single permutation of p elements 
can require a maximum time bound of 0(p) to get to the next permutation. Therefore with 
permutable graphs with {pi,p2, . . . ,p n } elements the maximum time bound is of the order of 
^2i=iPi- Since each permutable segment is contained in a single permutation then the upper 
time bound is 0(§) (where S is the set of segments). 

Similarly, if there are / flippable blocks then the bits representing the flipped status can be set in 
constant time (since they are being represented by a numerical value) ; however to translate this 
back to the status of each block requires each individual bit to be queried so needing an 0(f) 
upper time bound. If each block was flippable and every non static segment was in a different 
block then to update the status of every block would require an 0(§) upper time bound. 

Therefore, the maximum time bound to set the permutation order and flips is 0(S). 
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5.7 Edge Order Generation Algorithm 



A cyclic edge order can be defined such that each vertex has a parent and a stem edge incident 
(the first inbound and outbound edges, respectively) and these edges are contained in the same 
segment as that vertex. Each given edge forms an element of two doubly linked cycles such 
that for both incident vertices there is an edge anti-clockwise and an edge clockwise from that 
given edge - initially, each edge can be set that it is clockwise and anti-clockwise from itself and 
when it, or subsequent edges, are added to the cyclic order about an incident vertex then those 
cyclicly adjacent edges can be updated. 

Definition 4.4.3 (page 69) states how to generate a cyclic direction for each segment of a 
biconnected component. This translates into the algorithm below (taking into account that 
the containing blocks may have been flipped). 

Listing 5.7.1: Setting Segment's Cyclic Direction 

rootVertex . segment has clockwise cyclic direction 
for ( b £ BlockList ) { 

for ( s 6 b.alllnside ) 

IF ( b IS FLIPPED ) { 

S IS DIRECTED IN THE OPPOSITE CYCLIC DIRECTION TO S . parent 
} ELSE { 

S IS DIRECTED IN THE SAME CYCLIC DIRECTION TO S . parent 

} 

for ( s 6 b.allOutside ) 

IF ( b IS FLIPPED ) { 

S IS DIRECTED IN THE SAME CYCLIC DIRECTION TO S . parent 
} ELSE { 

S IS DIRECTED IN THE OPPOSITE CYCLIC DIRECTION TO S . parent 

} 

} 



For B blocks and S segments, this can be achieved in 0(S + B) upper time bound. However, 
since B < S this can be simplified to O(S) upper time bound. 

Expanding this to generate a cyclic edge order then definitions 4.4.4, 4.4.5 and 4.4.6 describe 
how to attach the head and tail vertices within an existing cyclic edge order. The algorithm 
below follows from those definitions. 

Listing 5.7.2: Generating the Edge Order for a Biconnected Graph 

for ( each edge (u — > v) £ root segment ) 

v. parent <— (u— >v) 
for ( each edge (u — > v) 6 root segment ) { 

u.stem <— (u—>v) 

u.stem is adjacent both anti— clockwise and clockwise from u. parent about u 

U . STACK <— EMPTY STACK 

} 

previous <— root segment 

for ( s £ SegmentList \{root segment} ) { 
while ( previous 7^ s . parent ) { 

pop from pre vious . get Tail Vert ex (). stack 
previous <— previous . parent 

} 

FOR ( EACH TREE EDGE — > VJ £ S ) 

v. parent «— 

FOR ( EACH NON HEAD EDGE (v — > w) £ S ) { 

v . stem <— (v— >w) 
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v . stem is adjacent both anti— clockwise and clockwise from v. parent about v 

V . STACK <— EMPTY STACK 

} 

let h <— s . headVertex ( ) 
let t 4— s.tailVertexQ 
let e <— s . tailEdge () 
let d •<— cyclic direction of s 

add s.headEdge{} to cycle about h adjacent to h. parent in opposite direction 
to d 

IF ( t . STACK I S EMPTY ) { 

add e to cycle about t adjacent to t . stem in direction d 
else { 

34 peek at (a, e, c) on t. stack 

35 IF ( d IS CLOCKWISE ) 

add e to cycle about t clockwise adjacent to a 

ELSE 

38 add e to cycle about t anti— clockwise adjacent to c 

39 } 

LET a «— EDGE ANTI— CLOCKWISE ABOUT t FROM e 
LET C <— EDGE CLOCKWISE ABOUT t FROM e 

push (a, e, c) onto t. stack 



Considering listing 5.7.2: 

Lines 1-7 consider the root segment and iterates over the segment's edges attach the parent 
(inbound) and stem (outbound) edges to each vertex and sets their initial cyclic order and sets 
an empty stack to contain structures needed for later embeddings. The time complexity of this 
operation is proportional to the number of edges in the root segment . 

Lines 12-15 handles backtracking when the algorithm has embedded all descendants of a given 
segment and the vertex stacks can have the triplet of cyclically adjacent edges relative to those 
descendants' tail edges removed as they are no longer relevant to the embedding. Each segment 
can only be added to, and hence removed from, the stack once so when iterating over all segments 
this check will be performed once per non-root segment and at most each segment can be popped 
from the stack once so in total this is 0(S). 

Lines 16-22 attach the parent and stem edges to each vertex about the non-root segments and set 
an empty stack to contain structures needed for later embeddings. Since each edge is contained 
in exactly one segment and each segment is iterated over exactly once then this and lines 1-7 
are performed in 0(£) time. 

Line 29 attaches the segments head edge to the head vertex (as per definition 4.4.4); this can 
be performed in constant time (since this is the addition of an element to a doubly-linked list) . 

Line 32 attaches the segments tail edge to the tail vertex in the case where no other ancestors 
(except the containing segment) are attached (as per definition 4.4.5) and can be performed in 
constant time. 

Lines 34-38 attach the segments tail edge to the tail vertex in the case where other ancestors 
are attached (as per definition 4.4.6) and can be performed in constant time. 

Therefore, lines 29-38 can be performed in constant time so these operations can be performed 
for all segments in O(S) time. 
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Examining the time complexity of the procedure then each segment is considered as is each edge 
and the total time complexity of the procedure is 0(£ + S). 



5.8 Planarity Testing Conclusions 

This chapter has shown how to: 

• Generate a Tremaux Tree in 0(V + £) upper time bound; 

• Partition the graph into segments in 0(V + £) upper time bound; 

• Test the graph for planarity in 0(S) (where S is the segments of the graph) and whilst 
performing this test identify flippable, permutable, rotatable and reversible segments; 

• Generate a permutation of the graph in a O(S) upper time bound; and 

• Generate a cyclic edge order for that embedding in 0(£ + S) upper time bound. 

Since, for connected graphs, both the number of segments and the number of vertices is less 
than or equal to one plus the number of edges then this can be simplified to conclude that all 
phases of the algorithm have an 0(E) upper time bound and that the execution of the algorithm 
is linear with respect to the number of edges of the graph. 



Chapter 6 



Benchmarking Methodology 



This chapter is a discussion of the process used to benchmark the performance of the algorithm. 
It will discuss: 

• What is software performance benchmarking; 

• Factors affecting the robustness of a software benchmark; 

• Mitigating against benchmarking factors; and 

• Analysis techniques to reduce the impact of unmitigated factors. 



6.1 What is software performance benchmarking? 

Software benchmarking is the process of executing a given piece of software to test it against a 
specified metric to give an indication of the software's performance [48, 86]. "Performance" could 
be measured in terms of: 

• Execution speed, where a smaller execution time (for the same effect) indicates higher 
performance; 

• Throughput, where a greater amount of processing in a given unit of measurement indicates 
higher performance. This is typically measured against time (i.e. frames per second in 3D 
graphics or transactions per second for database applications) but can be applied to other 
units such as cost, when looking at performance compared to total-cost-of-ownership, or 
Watts, when measuring the performance of portable devices where battery life is important; 
or 

• Correctness, where the benchmark is designed to validate the software against a set of 
predetermined criteria. 

In a perfect world the software being benchmarked would execute in a constant time every 
repetition and the process of benchmarking software would be a matter of simple comparison, 
unfortunately this does not happen as various factors affect the result. Therefore a significant 
effort is required to make sure that these factors are eliminated or minimised during the execution 
of the benchmark or in the analysis. When comparing benchmarks, they need to be comparable, 
repeatable and robust. 
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• Benchmarks are comparable when they are executed under identical conditions and 
variation in the results can be attributed to changes in the input conditions to the 
benchmark rather than to external factors. This means that when two benchmarks are 
compared they should have been executed using the same source code; compiled in the 
same way; executed using identical settings; and run in comparable environments (i.e. on 
comparable hardware and operating system). 

• Repeatable benchmarks are ones where the results can, within an acceptable margin of 
error to account for external factors, be reproduced given comparable execution settings 
and environments. Typically, a single instance of a benchmark is not enough to quantify 
performance and a series of comparable benchmarks should be used to give an estimate of 
the "average" performance so that extreme values can be detected as outliers and mitigated 
against. 

• Robust benchmarks ensure that the benchmarked quantity that which is measured and 
there are no other factors obscuring or distorting the measurement. This means that 
during the execution of the benchmark the external factors influencing the results are 
minimised and, during analysis, robust statistical measures are used to minimise the effect 
of outliers resulting from the external factors that cannot be eliminated. 

The remainder of this chapter will look at the benchmarking process and factors affecting the 
benchmarking of a planarity testing algorithm written in Java to test the execution speed against 
the hypothesis that the execution time increases linearly with graph size. 

6.2 Factors affecting the Robustness of a Software Bench- 
mark 

There are three broad areas where effects can impact on a benchmark; these are: software, 
hardware and environmental factors. 

Software factors are the effects of software other than the benchmarked application on the 
benchmark result. Typically these can be categorised into sub-groups relating to: the operating 
system (and can be further categorised into critical and non-critical services); processes and 
services the benchmark is reliant upon (i.e. a JVM or integrated development environment); 
and other applications. The impact of these factors is likely to be significant as other software 
will take processor time away from the benchmarked software and one interruption can result in 
a cascade effect where a later interruption may occur during the benchmark time frame because 
that time frame was extended due to an earlier interruption. 

Typically, benchmarking software or programming languages will have options (i.e. command 
line options on the JVM) to log interruptions (such as Just-In-Time compilation or Garbage 
Collection) or these can be built into the benchmarking software. However, when considering 
software that is more removed from the testing environment, it can be more difficult to monitor 
(and when there is the capability to monitor, it then the issue is synchronisation with the 
benchmarking process) and these factors are likely to have a significant impact on the benchmark 
and need to be mitigated against. Often the simplest mitigation is to stop as many programs 
and services from running as possible but, to be able to compare benchmarks, a consistent setup 
should be maintained during subsequent benchmarks. 

Considering the impact hardware has on benchmarking the execution time of an algorithm, 
there are very little in the way of hardware requirements. These include: a minimal user 
input to initiate the benchmarking process (but after that the process can be automated and 
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there is no futher user input); an output requirement to maintain a log of the benchmarked 
performance; and the most basic hardware requirement is the processing capability to perform 
the benchmark. Therefore the number of hardware factors can be immediately reduced to the 
smallest sub-set able to meet these capabilities and eliminate any additional factors that may 
arise from additional, unnecessary hardware. 

Of the required hardware capabilities: 

• User input is easily managed as it is only required to initiate the benchmark and thereafter 
the user can be disconnected to eliminate any variables this may introduce to the process. 

• Processing capability is a necessity and is, naively, assumed that for repeated execution 
of a benchmark the typical load on the hardware will be consistent; it is when additional 
software factors (i.e. the operating system) are involved that the performance obtained 
from the hardware is reduced and these are the factors that need mitigating by terminating 
as many software applications and services as possible before benchmarking. 

• Output is the most significant overhead, when considering hardware factors, as processing 
can, with sufficient resources, be performed in memory whereas recording the benchmark- 
ing result requires writing to disk and incurs a significant relative delay. However, logging 
results can, and should, be performed in the time between benchmarks and so mitigation 
for delays due to logging relies on the test suite accurately partitioning the results into 
time spent benchmarking a time spent on other tasks so as not to have erroneous results. 

Environmental factors are considered to be external to the hardware and software and can 
include temperature, humidity, power supply, or other similar effects; they are either small 
gradual changes, such as temperature variations, that are difficult to quantify the effect on 
performance; or are low-probability dramatic changes, such as power failure, that are typically 
terminal for the benchmarking process. Therefore, while their impact is noted for completeness, 
these factors are generally accepted to not be significant to the overall validity of a benchmark. 

In conclusion: environmental factors are believed to be either of negligible impact or have 
very low probability of occurrence and will be discounted. The major hardware factors can 
be mitigated for by using the minimum necessary hardware setup; removing the user from the 
system (as much as is practical); and making sure the logging of results is performed outside 
of the benchmarking period. The impact of software can be reduced, as with hardware, by 
using a minimal setup and when interruptions occur, they should either be monitored during 
benchmarking or, where appropriate, treated as outlying results and removed from the datasets. 
A more detailed discussion of specific software factors is included below. 
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6.3 Mitigating for Software Factors during Benchmarking 

This section deals with more specific software factors relating to benchmarking and, in particular, 
those relating to the Java Programming Environment. These include: 

• Clock Resolution; 

• Code Warm-up (Class Loading and Just-in-Time compilation); and 

• Garbage Collection 

6.3.1 Clock Resolution 

Timings in Java can be obtained using several methods [6, 71]: 

1. System. currentTimeMillis () returns the current time in milliseconds (ms), since 1st 
January 1970, but may have a resolution of tens of milliseconds depending on the operating 
system; this low resolution is a problem if the execution time approaches this limit. If the 
system clock is changed during a benchmark (due to changes in daylight savings time or 
Network Time Protocol synchronisation) this will result in erroneous reporting. 

2. System. nanoTime () returns the elapsed time from an arbitrary static time frame and is 
not related to the system clock or a wall clock. It is reported to nanosecond (ns) precision 
but is not necessarily nanosecond accuracy. 

3. java.lang. management. ThreadMXBean.getCurrentCPUTimeO returns a nanosecond pre- 
cision measurement based on CPU time for the thread; this is typically more resistant to 
interruptions than System. nanoTime () but the time for some operations, such as I/O, is 
platform dependent as to whether it is allocated to the program thread or a system thread. 
It also relies on native methods to access this information and so is not supported on all 
JVMs or platforms (and on the platform used for testing this method was indicated as 
being supported but always returned a time of zero nanoseconds). The other main issue 
with this method is that it is based on thread CPU time and if the process spawns multiple 
worker threads then the returned CPU time for the main thread may not accurately reflect 
the actual time spent on the task. 

The preferred method is to use System. nanoTime () as it is more robust 
than getCurrentCPUTime () and, typically, has a better resolution than 
System. currentTimeMillis () . The resolution of System. nanoTime () was tested using 
the sample code, shown in Appendix C.l, and the results are summarised in Table 6.3.1 
(shown in full in Appendix C.2); this shows the best resolution appears to be of the order of 
1 microsecond (/zs), with a mean of 1.3666ms, but even simple code (with sequential calls to 
record the time) can be interrupted by external factors and have delays of the order of 10ms. 
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Clock 

Tf O C t~\ Midi /~\ T"l 

(ns) 


Frequency 

(out of 
10,000,000 
repetitions) 


Cumulative 

(%) 




555,426 


5-55426 


978 


1,940,982 


24-96408 


1466 


2,493,535 


49-89943 


1467 


5,000,942 


99-90885 




1,813 


99-92698 
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99-94979 


2444 


1,277 


99-96256 


2445 


1,001 


99-97257 




9778 


39 


99-97736 


10266 


15 


99-97751 



100222 3 99-99502 





6486579 


1 


99-99999 


17440136 


1 


100-00000 



Table 6.3.1: Summary of Clock Resolution Times 



The execution time results showed a rough pattern: there are pairs of times Ins apart; and the 
increment between successive pairs is, typically, 489ns or a multiple thereof. An assumption 
can be made that the results Ins apart are due to rounding to the nearest nanosecond and the 
increment is related to the duration of one clock cycle but this is only supposition. It does 
highlight that there is a degree of granularity to the results and accuracy below approximately 
500ns does not appear to be achievable. 

The results also show it is possible for significant interruptions to occur between sequential 
calls to the timer and that: 0.0225% of the results showed a clock resolution above 10/is; 
0.005% had a resolution above 100/xs; and the minimum recorded resolution was of the order of 
tens of milliseconds (over 10,000 times greater than the maximum resolution). This shows the 
importance of taking repeated measurements and the impact that extreme outliers could have 
on the results as the full dataset has mean of 1367ns and standard deviation of 6199ns but if the 
results are cut off at 3 S.D. above the mean then 99.95% of the results remain and the mean is 
approximately the same at 1345ns but the standard deviation is significantly reduced to 224ns 
and is a closer representation of the spread of the data. 

The conclusion from this test is that the maximum resolution provided by System . nanoTime ( ) is 
approximately 1/is (achieved in approximately 30% of the results) but approximately 99.95% of 
the test show a resolution of 2/us or less and, therefore, the clock resolution should be considered 
accurate to the order of the nearest 10/xs. 
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6.3.2 Code Warm-Up 

Code warm-up encapsulates two problems: class loading/unloading and just-in-time compila- 
tion; both of these effects affect the results during the time it takes the JVM to "warm-up". 

Class Loading 

Class loading [86, chapter 6] is the process by which the Java Virtual Machine (JVM) loads the 
classes ready for first execution and typically involves disk I/O, parsing and verification; all of 
which greatly inflate the execution time of the first cycle through the program. In addition, the 
JVM can also decide to unload classes that have become garbage. 

There are two methods of detecting class loading and unloading: 

• The java.lang. management. ClassLoadingMXBean class has methods 
getTotalLoadedClassCount () and getUnloadedClassCount () that can be used to 
poll the JVM before and after benchmarking and an increase in either count indicates 
that class loading or unloading has occurred; or 

• The command line options -XX: +TraceClassLoading and -XX: +TraceClassUnloading 

will display on the standard output (if a console has been allocated) when a class is loaded 
or unloaded. 

Neither of these methods will print any timing data to show the performance impact that class 
loading has on the execution time. 

Testing the algorithm to determine the when the classes are loaded shows that the majority of 
the classes are loaded prior to benchmarking and, as expected, the remaining classes are loaded 
during the first execution cycle. Therefore the first result in the dataset should be considered 
suspect as it is likely to have been influenced by the effects of class loading. During execution, no 
instances of class unloading were detected so it is believed not to be a factor in the algorithm's 
performance but is mentioned for completeness. 
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Just-in-Time Compilation 

Just-in-Time (JIT) compilation is a feature of modern mixed-mode JVMs; the code is initially 
allowed to run in a purely interpreted mode while it profiles the execution and then after a 
number of cycles a JIT compilation will be performed on a given code block, where a class 
can be formed of many nested code blocks, and from then onwards the compiled code will be 
executed. This compiled code is used until the JVM detects that any of its assumptions used 
to compile the code are outdated, at which time de-optimisation occurs and the code block 
will return to running in interpreted mode and profiling will begin again; one example of this is 
"uncommon traps" [6] where the most likely path is compiled initially and atypical branches, such 
as exception paths, are left as interpreted code blocks but if detected may trigger recompilation 
of the code. 

There are two methods of detecting JIT compilation: 

1. The command line option -XX: +PrintCompilation will display an output to the standard 
output stream (assuming a console has been allocated) when a compilation occurs detailing 
(for the JVM used in testing): the sequential index given to the compilation; an identifier 
for the code block; and the number of bytes. It does not display the time spent performing 
compilation. 

2. java. lang. management . CompilationMXBean has a getCompilationTimeO method that 
returns the total time (in milliseconds) spent by the JVM in compiling code and by polling 
this at the start and end of the benchmark the time spent compiling (to the nearest 
millisecond) can be obtained. 

The following two snippets of the algorithm's output highlight problems with using these 
methods. In both cases the output has been modified to display as "execution time" minus 
"compilation time" (calculated using the CompilationMXBean interface and polling before and 
after the benchmark) equals "adjusted time" (all units are in nanoseconds). The code was 
executed with the command line option enabled so that both methods can be compared. 

Listing 6.3.1 shows execution of the algorithm that is interrupted during the generation of edges 
sides as the JVM compiles the java. lang. String: : indexOf code snippet (line 6); However, 
the compilation time shows that milliseconds were spent compiling code (line 7) as the total 
compilation time is likely to be less than 0.5 milliseconds and therefore rounded down to give a 
result of 0; this means that the millisecond resolution can negatively affect the results. 

Listing 6.3.1: Code Compilation - Rounding Errors 

1 Root : 1 

2 Timing Started 

a DFS Completed: 6328667 - = 6328667 

4 Segment Generation Completed: 3924312 - = 3924312 

5 Segment Embedding Completed: 4158000 - = 4158000 

e 1 java . lang . String :: indexOf (166 bytes) 

7 Edge Sides Generated: 4445956 - = 4445956 
I / 
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Listing 6.3.2 shows two features: firstly that the compilation highlighted on lines 10-11 took 
12 milliseconds to execute, however the code is recorded as having taken approximately 1.5 
milliseconds to execute and therefore the adjusted time is negative; and secondly, line 13 shows 
that the segment embedding was interrupted for 4 milliseconds for compilation (again giving a 
negative adjusted time) but there was no compilation displayed, immediately prior to this line, 
using the command line option whereas three compilations (lines 14-16) interrupt the phase 
succeeding it (line 17). 

Listing 6.3.2: Code Compilation - Sequencing Errors 

Root : 1 

Timing Started 

8 mgt aylor . d at as t r uct ur es . UnmodifiableLinkList : : addTail (141 bytes) 
DFS Completed: 1514089 - 12000000 = -10485911 

Segment Generation Completed: 1156222 - = 1156222 
Segment Embedding Completed: 2064089 - 4000000 = -1935911 

9 mgtaylor . d at as t r uct ur es . UnmodifiableLinkList :: getTail (17 bytes) 
11 mgtaylor . datastructures . UnmodifiableLinkList$ 1 :: next (30 bytes) 

10 mgtaylor . graph . Edge :: isDFSStem (18 bytes) 

Edge Sides Generated: 2993956 - 1000000 = 1993956 
I J 

These results show that: 

• The millisecond resolution provided when polling the JVM is not always fine enough to 
detect when a JIT compilation has occurred; 

• There is a discrepancy between the duration of JIT compilation (milliseconds) and the 
more accurate benchmark times (nanoseconds) and can result in a negative adjusted time; 

• The command line option does not give any feedback on the time spent on compilation 
and so is of limited use in benchmarking; and 

• The command line option only appears to identify when compilation of a code fragment 
has completed and is not a reliable indicator of how the compilation time is spread. 
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Effects of Code Warm-Up 



Figure 6.3.1 shows a scatter plot for the execution times of the algorithm on a 1250 vertex 
triangular prism graph (described in section 7.3.1) where benchmarking 1000 repetitions of the 
algorithm has occurred immediately after initialising the JVM and demonstrates several features: 



• The top plot shows that the first result is of a different order of magnitude from the 
majority of the results and is indicative of the effect of class loading; 

• The results affected by garbage collection are spaced at approximately regular intervals. 
The bottom scatter plot (showing the results up to the 98th percentile) shows a 
garbage collection occurred every 55-65 repetitions - equivalent to a garbage collection 
approximately every 3 tenths of a millisecond; 

• Over the period up to the 7th garbage collection (389th repetition), there are steps in the 
scatter plot reflecting a gradual improvement in the execution representative of the effects 
of JIT compilation; and 

• After the 7th garbage collection, the plot stabilises to have to a mean execution time of 
10.82 ms (with a standard deviation of 0.65 ms) and the effects of code warm-up appear 
to have disappeared. 
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Figure 6.3.1: Code Warm-Up for 1250 Vertex Triangular Graph (Root = 1) 
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Immediately after the algorithm was run for another 1000 repetitions, this time using the 2nd 
vertex as the root of the graph; comparing the results shown for the 1st (Figure 6.3.1) and 2nd 
(Figure 6.3.2) vertices as roots shows that once the JVM has performed any JIT compilations 
and is stable that, with the exception of a few outliers and the results affected by garbage 
collection, the results are approximately constant (for 2nd vertex as the root, mean is 11.36ms 
and standard deviation is 0.18ms). 
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Figure 6.3.2: Code Warm-Up for 1250 Vertex Triangular Graph (Root = 2) 
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Mitigating against Code Warm-Up 

Without a deeper understanding of the workings of a JVM, it is difficult to make sense of the 
nuances of how compilation occurs and is reported; however, the conclusion can be drawn that 
both class loading and JIT compilation present a problem to performing benchmarking tests 
and it is difficult, in both cases, to accurately quantify their effect. 

There are two ways to mitigate against Code Warm-Up: 

• Run through a number of iterations through the algorithm before recording any data 
ensuring that the majority of the classes are loaded and JIT compilation has occurred. 
The Java Hotspot Server Virtual machine profiles a given code block for 10,000 iterations 
before performing compilation [6] therefore a number of repetitions in excess of this should 
insure that the code has been "warmed-up" and will run in a steady state. This will not 
cover instances where rarely used code segments are accessed and in these cases it may take 
longer to reach the point at which JIT compilation occurs and will have to be mitigated 
against in another way; such as 

• Removing or reducing the impact of the upper percentiles of data in the dataset. Code 
warm-up increases the execution time and means that data points affected by this will 
fall into the upper percentiles of the data set and can be treated as outliers and handled 
either via pruning the data set (ensuring that removed results are outliers and not part 
of a distribution with a heavy tail) or using analysis techniques that can robustly handle 
outliers, to minimise the distortion these create. 
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6.3.3 Garbage Collection 

Of the interruptions that occur during execution, garbage collection (GC) is the most frequent 
and regularly reoccurring issue; this means that dealing with the effects of garbage collection is 
one of the most pressing problems with benchmarking. 

Java provides several methods of analysing the impact garbage collection has on the performance, 
including: 

• The java. lang. management. GarbageCollectorMXBean interface provides two methods 
to query the JVM regarding the total number of garbage collections that have occurred 
and the total collection time (in milliseconds) . This interface allows the JVM to be polled 
before and after a benchmarking loop to calculate the increase in time spent on garbage 
collection. 

• The command line option -XX: PrintGCDetails adds verbose output to the standard 
output channel (if the console is enabled) . 

There are 4 issues that need to be taken into account when analysing the impact of garbage 
collection: 

• Timing resolution for garbage collection reporting methods; 

• False positive or negative reporting of garbage collection instances; 

• Similarity /dissimilarity of data sets affected and unaffected by garbage collection; and 

• The frequency garbage collection as graph size increases. 

Garbage Collection Timing Resolution 

Considering the timing resolution, the GarbageCollectorMXBean interface is specified to have 
millisecond granularity (about 1000 times worse than the clock resolution, see section 6.3.1) and 
therefore rounding errors in the reported garbage collection time will be significant for results 
that are of a similar or smaller order of magnitude; as the typical execution time of a 1000 vertex 
Triangular Prism graph is less than 9 milliseconds, this is a significant issue. Compared to this, 
the command line option provides timing details with a 100 nanosecond precision; the accuracy 
of these results is not commented on in the API documentation but can be assumed to have 
an accuracy that is at best the same as the clock resolution (approximately l-2microseconds) . 
Given the resolutions provided by the two methods, it is preferable to use the command line 
option for the greater reported accuracy. 

Using the command line option requires that the start and end of any benchmarking period 
is output to the standard output channel and the console output must be synchronised with 
this (see section 6.3.4 for more details of synchronisation issues) so that garbage collection 
reporting is correctly ordered within the log file. The information collected from the 
GarbageCollectorMXBean interface can be polled directly from the JVM and integrated into the 
stream used by the benchmarking process to log results and so does not require synchronisation 
with the console; this may result in a reduced error rate due to any synchronisation issues but 
this is of lower impact than the issues created from the lower timing accuracy. 
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False Positive Reporting of Garbage Collections 

False positive reporting of garbage collection occurs when the JVM reports a garbage collection 
and it is falsely determined to have occurred during a period of benchmarking when it did 
not and can result in execution times lower than expected (or even negative, similar to the 
log snippets shown in section 6.3.2). The pseudo-code snippet below (Listing 6.3.3) gives the 
typical structure for performing a benchmark and identifies two areas where, if interrupted by 
garbage collection during this period of execution, a false positive garbage collection will be 
reported. These areas are impossible to eliminate and mitigation for them has to take the form 
of ensuring that there are as few operations between logging that the benchmarking process has 
started (ended) and recording the start (end) time for the benchmark. 

Listing 6.3.3: Garbage Collection - False Positive Results 

i log( "Start Benchmark" ); 

3 // False positive area #1 

5 startTime = getTime() ; 

6 performBenchmark ( ) ; 

7 endTime = getTimeQ ; 

9 // False positive area #2 

n log( "Benchmark Finished" ); 

12 elapsedTime = endTime — startTime ; 

13 log( "Benchmark Time: " + elapsedTime ); 



Examining the 1000 vertex triangular prism graph dataset used in the next chapter, false positive 
results were easily identifiable as the garbage collection time was greater than the execution time 
and so the adjusted time (execution time minus garbage collection time) was negative. Looking 
at the error rate there was less than 10 out of 1,000,000 results where a false positive detection 
of garbage collection was made and therefore the overall impact is likely to be negligible. 

While the garbage collection time is greater than the total execution time this will result in a 
negative adjusted execution time, which is nonsensical and simple to treat as an outlier which 
can be removed from the dataset. When the total execution time is greater than the garbage 
collection time then determining whether the result is a false positive detection is more difficult 
but can be achieved by looking for garbage collection events where the total adjusted execution 
time is significantly lower than the corresponding minimum execution time for the data not 
interrupted by garbage collections; while this is not impossible to identify it can be subjective 
when setting the threshold for identifying false positives. A more appropriate method is to 
use robust analysis techniques (discussed in section 6.4) that account for outlying results when 
analysing the results. 
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False Negative Reporting of Garbage Collection 

False negative results occur when garbage collection occurs during the benchmarking process 
but it is not reported (or is reported outside of the logged time frame where the benchmark 
occurred). This can be due to: the order in which logging and timing occurs; synchronisation 
issues between logging the benchmark results and the JVM output that reports on Garbage 
Collections (see section 6.3.4); or due to garbage collection executing concurrently with the 
benchmark but not being reported until completion of the GC, which may be outside of the 
benchmarking timeframe or even during a different benchmark. 

Listing 6.3.4 (where the order of starting/ending logging and timing is reversed from listing 
6.3.3) gives an example of when false negatives can occur if GC occurs whilst timing but outside 
of logging that timing is occurring. Given that false positives results, typically, result in negative 
adjusted execution times (as discussed above), and are easily identifiable, whilst false negative 
results have no distinguishing features from outliers generated by other unidentified factors then 
it is better to use the structure of listing 6.3.3 to log results as it will reduce the impact of 
outliers. 

Listing 6.3.4: Garbage Collection - False Negative Results 

i startTime = getTimeQ ; 

3 // False negative area #1 

5 log ( "Start Benchmark" ); 

6 performBenchmark ( ) ; 

7 log( "Benchmark Finished" ); 

9 // False negative area #2 

n endTime = getTimeQ ; 

12 elapsedTime = endTime — startTime ; 

13 log ( "Benchmark Time: " + elapsedTime ); 



Considering synchronisation: logging occurs via the standard output stream whilst reporting 
GC interruptions occurs through the Console interface; having these two reporting methods 
unsynchronised can introduce errors in the reporting process (either false positive or false 
negative). Mitigating for synchronisation issues is discussed in more depth in section 6.3.4 
but as long as the console and standard output can remain synchronised then instances of GC 
are reported inline with the logging and this is considered to be of low impact. 

Considering concurrent GC: Normally, garbage collection pauses execution of the program and 
restarts it after the process has competed so there are no concurrency issues. Concurrent garbage 
collection is a side effect of activating the JVM with the non-standard option (-Xincgc) and, 
therefore, it is considered to be of low impact as it can be managed during the setup of the 
empirical testing. 

If a false negative result does occur then it results in an increased execution time and can 
introduce an outlier within the data set; this can be mitigated for using robust analysis techniques 
(discussed in section 6.4) that are resistant to the presence of outliers. 
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Similarity of Data Affected and Unaffected by Garbage Collection 

A benchmark consists of a set of repeated executions of the algorithm for a given, static, set 
of input conditions (graph type [see Section 7.3], size, root vertex) and the output of each 
repetition within the benchmark includes a report on the duration of algorithm's execution; this 
allows the "average" duration of the algorithm's execution to be calculated and compared with 
other benchmarks. Also output is whether that execution period was reported to have been 
interrupted by garbage collection and the duration of that interruption, so an adjusted time 
can be calculated for those repetitions subtracting the duration of GC from the total duration 
of execution. This allows a benchmark to be partitioned into disjoint data sets affected and 
unaffected by garbage collection. 

It is important to ensure that the results affected by garbage collection, after adjusting for the 
reported GC time, do not distort the unaffected data. If the data sets are dissimilar then, 
even after adjustment based on the reported GC duration, there are still additional factors, 
compared to the non-GC data set, that are influencing the location or shape of the distribution 
and so inclusion of the GC data may skew any calculation of an "average" exectution time for 
that benchmark. In this case, the GC data should not be used in the analysis as it is not 
representative of the rest of the (non-GC) data. 

If the data sets are not dissimilar then there is a lack of evidence that the GC data is influenced 
by additional factors and so the conclusion can be drawn that GC could be mitigated against 
by calculating the adjusted execution time. 



Examining the similarity (or lack thereof) 
between the datasets affected and unaffected 
by garbage collection requires a measure 
of similarity. This can be found us- 
ing, amongst others 1 : the Two-Sample 
Kolmogorov-Smirnov (K-S) Test [70], which 
considers the maximum distance between the 
empirical cumulative distribution functions 
(ECDF) of each sample; or the Two Sample 
Cramer- von-Mises (CvM) Test [1, 70], which 
considers the sum of the squared distances 
between the ECDFs. Both are non- 
parametric, distribution-free tests to quantify 
the distance between the ECDF of two 
samples. The null hypothesis for each test is 
that the samples have both been drawn from 
the same distribution (or from distributions 
with similar location and shape) - rejection 
of the null hypothesis indicates that the two 
samples are drawn from distributions that are 
not similar in location and shape. 



Empirical Cumulative Density Function of Two Randomly 
Generated Distributions Approximating N(0.1) and N(0.1,0.9| 




Figure 6.3.3: Example comparing ECDFs of 
samples drawn from two normal distributions. 



Figure 6.3.3 shows the ECDF step "curves" for two samples of data, drawn randomly from the 
normal distributions A(0, 1) and N(0.1, 0.9). The region between the two step "curves" delimits 
the (vertical) distance between ECDFs at each data point, as used by the CvM test, and the 
vertical arrow marks the maximum (vertical) distance within this region, as used by K-S test. 

1 Other tests include: Kuiper's test [70], a modification of the K-S test to consider the maximum deviation above 
and below the two ECDFs; Student's f-test, a non-distribution-free test, used to compare two samples drawn 
from normal distributions with different means and equal (or non-equal for Welch's t-test) variations; or Hellinger 
Distance [45] (and the related Bhattacharya distance) for comparing lack of similarity (distance) between two 
distributions. 
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For a given graph, a set of benchmarks (where each benchmark is a series of repeated executions 
of the algorithm for that graph using a single vertex as root) can be generated such that there is 
one benchmark for each root vertex; each benchmark can then be partitioned into the samples 
affected and unaffected by GC and a rejection/non-rejection of the null hypothesis, that the 
samples affected and unaffected by GC are drawn from distributions with similar location and 
shape, can be calculated, using K-S and CvM tests, for that benchmark. Table 6.3.2 lists the 
percentage rejection of the null hypothesis from the set of benchmarks covering all root vertices 
of various graph types and sizes. I.e. Table 6.3.2 shows for a 500 vertex Triangular Prism 
Graph, giving 500 benchmarks (one for each root vertex), that: in 99.4% (497 out of 500) of 
those benchmarks the K-S test rejected the null hypothesis, indicating that the samples affected 
and unaffected by GC are from dissimilar distributions; and in 100% (500 out of 500) of those 
benchmarks the CvM test rejected the null hypothesis. 



|V| 


Null Hypot 
Triangular 

Prism 
K-S CvM 


siesis (H ) Rejecl 
Planar Wheel 
K-S CvM 


;ed (% of |V| Ro< 
Ordered Face 

Trisection 
K-S CvM 


at Vertices) 
Random Face 

Trisection 
K-S CvM 


250 


100-000 100-000 


99-200 100-000 


99-200 99-600 


100-000 100-000 


500 


99-400 100-000 


100-000 100-000 


97-200 97-800 


100-000 100-000 


750 


84-267 85-200 


99-333 99-467 


66-533 57-600 


52-400 52-800 


1000 


87-000 90-500 


90-800 91-300 


90-000 93-000 


51-200 43-200 


1250 


93-120 92-720 


91-600 92-560 


98-400 99-280 


50-000 52-320 


1500 


98-867 98-200 


85-133 87-800 


99-200 98-867 


88-800 84-400 



Table 6.3.2: Dissimilarity between Datasets Affected and Unaffected by Garbage Collection 



These results show a very high rate of rejection for the null hypothesis indicating that, even 
after subtracting the recorded duration of the garbage collection from the benchmarked time, the 
data-sets affected and unaffected by garbage collection are dissimilar. The results for Random 
Face Trisection Graphs do show a marked reduction in the rejection rate when compared to the 
other results; however the rejection rate is still, typically, above 50% which suggests that the 
inclusion of garbage collection tainted results would distort the distribution and so should not 
be included in the data-set. 
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Frequency of Garbage Collection as Graph Size Increases 

Garbage collection (GC) is the most obvious external factor influencing the results and, as 
discussed previously in this chapter, is relatively simple to identify and can be mitigated against 
by removing the data tainted by GC from the analysis. In doing so, this reduces the data set 
and increases the chance that outliers will have a greater impact on the results. As such it is 
important to understand when a saturation point will be reached and 100% of the results are 
likely to be tainted by GC. 
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Ordered Face Trisection Graph - Number of 
Data Points Uninterrupted by Garbage Collection 
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Figure 6.3.4: Number of Data Points (Out of 100) Unaffected By GC for Different Graph Types 
(Root = 1st Vertex) 



Figure 6.3.4 shows the number of data points untainted by GC (out of a sample size of 100 for 
each graph size) and exhibits an, approximate, trend that F = — 3 x 10~ 8 V" 2 — 1 x 10~ 3 V + 100 
(where F is the percentage of the data points that are untainted by GC and V is the graph 
size) and the reverse: V — ^ 1 g^"' q - s ~~^ ■ Given this prediction then 100% of the results will be 
tainted by GC for graphs of approximately 43400 vertices. 

Given that as graph size increases then so does the execution time of the algorithm and the 
proportion of results tainted by GC also rises then maintaining a reasonable sample size of 
untainted data becomes increasingly (and prohibitively) time consuming. The conclusion that 
can be drawn from this data is that for a large proportion (75%) of the data set to be untainted 
by GC, then the graph size needs to be less than 16500 vertices. 
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Mitigating against Garbage Collection 

Garbage Collection can be mitigated against by: 

• Recording when garbage collections occur and ensuring that this is synchronised with the 
algorithm's output. 

• Remove any data points tainted by garbage collection from the data set (this deals with 
the issues of lack of similarity between the distributions for data tainted and untainted by 
GC and of false positive recordings of garbage collection). 

• Limiting the number of vertices in a graph; this is for practical reasons and prevents 
large proportions (or the entirety) of the data set being affected by garbage collection and 
requiring that a disproportionately large sample size be generated to obtain a small sample 
of data that is untainted by garbage collection. 

6.3.4 Logging Results 

Logging results is necessary to record and evaluate the performance during benchmarking but it 
is important that the process of logging results does not, itself, distort the benchmarking process 
and also that it accurately records the events in the order in which they happen. 

Making sure that the logging process does not interfere with the benchmark is relatively trivial 
as it requires the benchmarking to be timed but for the logging process to happen outside this 
timing loop, as shown in the pseudo-code snippet below. What is less trivial is the possibility 
of synchronising the benchmarking output with additional output (i.e. from the Java Virtual 
Machine to monitor garbage collection or Just-in-Timc compilation) and making sure that false 
positives and negatives do not impact the benchmark when logging additional events. 

The issue of synchronisation of program output during logging is complicated by the options 
available to output results in java. Some of these methods include: 

• Textual output can be sent to the command line, when the Java Virtual machine (JVM) 
is initialised, using the standard output stream. This output can be redirected on the 
command line or programmatically using the System. setOutO method or if the command 
line buffer is large enough then the output can be manually copied to a file after the 
benchmarking process has been completed but this is potentially prone to errors from the 
user and is time consuming; 

• Error messages are also displayed on the command line using the standard error streams, 
however it is not synchronised with the standard output stream and so if the granularity 
and synchronisation of result reporting is important then only one stream should be used. 
If the output is redirected from the command line then the standard error is also redirected 
but can be redirected separately using the System. setErrO method; 

• Output from the JVM is typically made to the system console and includes verbose output 
regarding garbage collection and just-in-time compilation, if enabled with the appropriate 
command line flags. The system console is, by default, created when the JVM is started 
from the command line if, and only if, the standard output and error streams are not 
redirected. The behaviour of the system console when output streams are redirected is 
dependent on the platform but the typical behaviour is that the console is not initialised 
and the optional JVM output is not available; 
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• The JVM provides an option (-Xloggc) to log garbage collection information directly to a 
file, complete with timestamps. However, these timestamps are generated using the "wall" 
clock and have millisecond (or, dependent on platform, tens of millisecond) accuracy; 
when sub-millisecond accuracy is required this makes it difficult to synchronise two log 
files, especially if System. nanoTime () (see section 6.3.1) is used as this method is only 
useful in measuring elapsed time (as it uses an arbitrary reference point for measurement, 
set during JVM initialisation or when first invoked, rather than a fixed point in time) . 

• Results can be output directly to a file, however, this does not output JVM information sent 
to the console and adds the complexity of synchronising this additional JVM information. 

• An integrated development environment (IDE) can be used to manage the command line 
output. One example of this is the Eclipse IDE [24], which provides an option to redirect 
the console output (including the standard output and error streams) to a file. This 
manages the requirement of keeping the console and standard output stream synchronised 
but adds the overhead of having another application running in the background. 

Given these methods and the particular importance of monitoring the impact of garbage 
collection, it is important that the results can be properly synchronised and while using an 
IDE may add additional load on the processor it significantly simplifies the analysis of the 
results. 

6.4 Analysis Techniques to Reduce the Impact of Unmiti- 
gated Factors 

Mitigating for the impact of external factors (hardware, other software or JVM issues) will 
reduce the likelihood of outliers but there will be some factors that either cannot be (fully or 
partially) mitigated for or have not been identified. These factors will introduce outliers into 
the dataset and can skew the results. 

For large sample sizes, outliers are to be expected as part of the distribution and may provide 
useful cues as to the shape of the distribution; in this case outliers should be retained within 
the dataset and the analysis should be robust enough to cope with their presence. When 
measurement errors occur, such as interruptions due to execution of unrelated software, the 
resulting data is unrepresentative of the underlying distribution and can cause the results to be 
skewed. 



6.4.1 Robust Curve Fitting Techniques 

The overall aim for the benchmarking process is to test the hypothesis that the algorithm runs in 
a given (linear) time as the graph size increases; this means that during post-benchmark analysis 
it is the upper bound of the time complexity that is relevant in testing this hypothesis. With 
this in mind, if the upper bound of the time complexity introduced by any unmitigated factors 
has a greater exponent than the algorithm's execution time complexity then the unmitigated 
factor will dominate the analysis rather than the algorithm. There is little that can be done 
to separate these factors without additional timing information so the benchmarking process is 
reliant on the fact that any unmitigated factors must have a time complexity that is the same 
or better than the algorithm's. 

The other issue with unmitigated factors is the issue of intermittent interruptions (such as from 
garbage collection) that will introduce extreme values into the results; this can either indicate 
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an erroneous reading (such as from garbage collection) or as part of a distribution with a heavy 
tail, in which case assumption that the distribution is part of a normal curve and removal of 
the extreme values as outliers can distort the results. It is necessary to test the shape of the 
distribution before treating results as outliers. 

For simple curves (polynomial, logarithmic, exponential, etc), ordinary linear least squares 
(OLS) regression [37, Pg. 137-139] provides a method of mathematically calculating the 
coefficients of a curve so as to find the best fit. OLS works by considering the coefficient of 
each term in the design model used to specify the curve; minimising the sum of the square of 
the residuals generates a series of simultaneous linear equations which can be solved to calculate 
the 'best fit' coefficients. 

OLS will find a single, stable solution to the problem; however, it is not resistant to the presence 
of large outliers, particularly at extreme x values where the presence of an outlier can greatly 
skew the coefficients of the fitted curve. Figure 6.4.1 shows 20 data points fitted to the y = 
2x 3 — 38x + 19 curve for x values between -10 and 9, the 21st data point is at (10, 0). The 
best-fit curves for y = ax 3 + b (green), y — ax 3 + bx 2 + c (red, overlaid by the cyan curve) and 
y = ax 3 + bx 2 + cx + d (cyan) are shown with the equations in the legend with the calculated 
coefficients; this demonstrates the fact that a single outlier at the extreme of the dataset has 
an impact such that the red and cyan lines almost overlap and the x 2 term is given greater 
significance than the x term in the last equation when it is not in fact the case. 

1500r 




Figure 6.4.1: Least Squares Curve Fitting 



There are various alternatives to OLS that provide a better fit to the curve in the presence of 
outliers. One of these is to use a weighting on the data to give less importance to outlying 
data points; there are various weighting functions that can be used, including squared errors, 
absolute errors, Winsorized errors or Tukey's biweight (or bisquare) function. The last two 
weighting functions are used to trim or taper the errors such that the greatest outliers have a 
reduced effect on the regression analysis. 

In addition to weighting the data, the process can be improved iteratively; an initial estimate of 
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the curve fit is given using OLS, then a weighting function is applied with a scale factor to reduce 
the impact of outliers and subsequent iterations are used to adjust the scale factor to improve 
the quality of the fit. This method is known as Iteratively Re- Weighted Least Squares (IRWLS) 
[60, Pg. 818-824] and typically gives an improved fit to the data in the presence of outliers; 
this is visually demonstrated in Figure 6.4.2, displaying best-fits to the same three curves as 
before (this time with red and green almost overlapping), which shows that, in all cases, both 
the outlying data-point and the x 1 term in the best-fit curves are given a lower weighting when 
compared to Figure 6.4.1. 
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Figure 6.4.2: Iteratively Re-Weighted Least Squares Curve Fitting 



When analysing the goodness-of-fit for a design model it is, again, important to use a robust 
statistic. OLS minimises the square of the residual errors, as such the optimal solution using 
this method will be identified by the lowest Root Mean Square Error (RMSE); however, as 
with OLS, the RMSE is greatly affected by the presence of outliers as the sum of the square of 
many small values can be dwarfed by the square of a single large value. In this case, the Mean 
Absolute Error (MAE) provides a better [60, Pg. 722-723] estimator for goodness-of-fit, as it is 
not as skewed by large outliers. This can be seen in Table 6.4.1, where OLS finds the optimum 
fit to minimise RMSE but IRWLS produces a near exact match to the curve however the RMSE 
metric indicates that it is the worst fit to the curve; if, instead, the MAE is compared then all 
the fits produced by IRWLS are an improvement on the OLS solutions and the correct solution 
is clearly highlighted by the metric. 
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Fitted Equation 


RMSE 


MAE 






(To 3 S.F.) 


(To 2 D.P.) (To 2 D.P.) 




V 


= 1.10a; 3 - 59.0 


284.95 


173.97 


OLS 


V = 


1.10a; 3 - 4.63a; 2 + 111 


241.51 


156.67 






y 


= 1.47a; 3 + 11.8 


335.20 


146.89 


IRWLS 
(Fig. 6.4.2) y = 


y = 


1.46x 3 - 0.560a; 2 + 30.0 


324.39 


142.84 


2.00a; 3 - 


- 2.13 x 10- 15 a; 2 - 38.0a; + 19.0 


357.66 


78.04 



Table 6.4.1: Comparison of Ordinary and Iteratively Re- Weighted Least Squares 



The MAE provides a metric to compare different best fit-models and the lowest MAE indicates 
the most appropriate fit to the empirical data. Therefore, the use of robust curve fitting 
techniques (Iteratively Re-weighted Least Squares) and statistics (Mean Absolute Error) will 
give a better solution in the presence of outliers and in identifying the comparative goodness- 
of-fit of different design models. 



6.5 Benchmarking Methodology Conclusions 

Table 6.5.1 summarises the various bechmarking factors detailed earlier in this chapter and the 
ways that they can be mitigated. The occurrence associated with each factor is an indication of 
how prevalent that factor is. The severity associated with each factor is an indication of much 
the factor affects the benchmark compared to the ability to mitigate against its effect; a low 
severity indicates a factor that either of little impact or that is realtively simple to mitigate 
against whereas a high severity indicates a factor that has a large impart on the benchmark and 
is is difficult to mitigate against. 



Table 6.5.1: Summary of Benchmarking Factors 



Factor 


Description 


Occurence 


Severity 


Mitigation 


Ordinary 


External effects such as 


Rare 


Nil - Low 


Discounted due to negligible 


Environmental 


variation in temperature 






impact and cost of 


Factors 


or humidity. Requires 






mitigation. 




specialist equipment to 










monitor and control. 








Hardware & 


Hardware or software 


Rare 


Nil - Low 


Keep constant hardware and 


Software Setup 


setup changes between 






software setup for all BMs. 




BMs producing 










incomparable results. 








Clock 
Resolution 


Clock resolution provides 
minimum limit on valid 
benchmark times. 


Constant 


Low 


Use System. nanoTime () . 
Results should only be 
considered accurate to the 
resolution of 10^is. 
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Factor 



Description 



Occurence Severity Mitigation 



Code Warmup 



User 

Interaction 



I/O 



Software 
Interruptions 



Garbage 
Collection 



Terminal 

Environmental 

Factors 



Interruptions due to 
class loading and JIT 
compilation. 



Disruption to 
benchmark's (BM) 
execution through user 
ion. 

Logging results adds an 
I/O overhead to the BM 
process 



Operating System or 
other processes interrupts 
BM 



Garbage Collection 
interrupts BM 



During 
Startup 



Low 



Rare 



Low 



Frequent Medium 



Frequent Medium 



Run the code for at least 
10,000 iterations before 
logging results. 
Generate repeated results. 
Use robust analysis to 
minimise effect of outliers. 
Automate the BM process, 
removing need for user 
interaction. 

Log results between, and not 
during, BMs. 

Generate repeated results. 
Use robust analysis to 
minimise effect of outliers. 
Stop all unnecessary 
applications & services. 
Generate repeated results. 
Use robust analysis to 
minimise effect of outliers. 



Frequent 



High 



External effects such 
as power or hardware 
failure. 



Rare 



Log GC interruptions using 
command line option. 
Synchronise Console and 
Standard Output Stream 
using IDE. 

Discard results tainted by 
GC. 

Avoid false negative GC 
results. 

Use non-concurrent Garbage 
Collector. 

Test graphs with less than 
43,200 vertices (100% GC 
Saturation) . 
Terminal Discard terminated BM and 
repeat. 



Chapter 7 



Empirical Testing 



The aim of this chapter is to present the results of empirical testing of an implementation to 
demonstrate examples of the linear execution time theorised in chapter 5 and includes: 

• Discussion of a Java implementation (source code contained in appendix D) of the planarity 
testing algorithm; 

• Plan for empirical testing of implementation; 

• Overview of different graph types, their properties and algorithms for generation; 

• Empirical testing results for maximal planar graphs of constant size and varying root 
vertex; 

• Empirical testing results for maximal planar graphs of constant root vertex and varying 
size; 

• Empirical testing results for biconnected sub-graphs of maximal planar graphs of constant 
root vertex and number of vertices and varying number of edges; and 

• Empirical testing conclusions. 
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7.1 Implementing the Planarity Testing Algorithm 

Appendix D contains Java source code for an implementation of the algorithm used later in this 
chapter to test efficiency of the algorithm. 

The source code is separated into several groups of packages: 

1. The core classes related to the planarity testing and embedding algorithm. This includes: 

• The basic data structures relating to lists and permutations (appendix section D.l, 
page 240) used throughout the planarity test; 

• The core graph classes (Block, Edge, Graph, Path, Segment and Vertex) containing 
the implementation of the planarity testing and embedding algorithm (appendix 
section D.2, page 268); and 

• Classes relating to the generation of graphs with specific properties (appendix 
section D.3, page 327). 

2. The test harness used to generate specific benchmarks during empirical testing and 
ancillary utilities to process the log files (appendix section D.4, page 344). 

3. A Graphical User Interface for visualisation of graphs and their segment and block 
properties (appendix section D.5, page 363). This is not required for the scope of the 
empirical testing but is presented, for completeness, as a method of visually inspecting the 
properties generated during an embedding and of manipulating embeddings by changing 
segment permutations and block flips. 

4. A utility class (appendix section D.6, page 419) to generate a graphical (IATf^X PGF/TifcZ) 
representation the segment hierarchy as used in section 7.3.8 (page 138); again, this is not 
required for the scope of the empirical testing but is presented for completeness. 

7.1.1 Aims and Limitations of the Planarity Testing Algorithm 

The aim of this testing is to demonstrate the linear execution time of the software in the case 
of biconnected graphs and, correspondingly, the focus of the implementation is on biconnected 
(and not connected graphs). As such, the capability provided by the source code includes: 

• Tests for planarity by generating an embedding of a connected graph; 

• Identifies static segments; 

• Identifies flippable blocks which define a Whitney flip within an embedding; 

• Identifies groups of permutable segments; 

• A method for flipping blocks and permuting groups of permutable segments; 

• A method for generating a cyclic edge order given a fixed flippable status for each block 
and a fixed order for each group of permutable segments. 

However, since the algorithm's focus is on testing linear execution time, it's capability for 
handling separable graphs is limited to specific functionality where a linear execution time 
is theorised to exist. In particular, it can generate all possible embeddings of each biconnected 
component but does not consider the multitude of arrangements when combining the embeddings 
of those separable components, as the process of re-arranging those components does not have 
a well defined linear-time implementation, and instead a single embedding of those combined 
components is generated (which can be performed in linear-time); i.e. the effect of manipulating 
the rotatable, reversible and outer reversible nature of segments in each biconnected component 
is not considered. 
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7.2 Empirical Testing Plan 

Chapter 5 presents an algorithm to test a (bi)connected graph for planarity of by generating an 
embedding of that graph. As part of the generation process, the algorithm constructs a data 
structure representing possible permutations of the embedding by identifying Whitney flips or 
permutations of segment order. Two additional phases of the algorithm are presented to: reorder 
the data structures representing the permutations of the embedding; and, given an order of those 
data structures, to generate an cyclic order for the edges incident to each vertex. 

Considering the input variables to the algorithm, the following can be varied: 

• The graph; this can be further considered in terms of: 

— The graph's structure; 

— The number of vertices of the graph; 

— The number of edges of the graph; or 

— The initial order for edges incident to each vertex. 

• The choice of root vertex. 

To give the testing an upper bound, a limiting case can be identified when the graph has the 
maximum possible edges per vertex without being non-planar. Multi-graphs can be excluded 
(mainly in the interests of simplicity and expedience), since every multi-graph can be reduced to 
an equivalent minor by deleting duplicate edges so if that minor is planar then the multi-graph is 
also planar and, conversely, if multi-graphs were considered then no upper bound can be placed 
on the number of edges. Given this constraint, then limiting case occurs when the graph is 
maximal planar. 

In a similar vein, chapter 6 identified that at approximately 15,000 vertices then ~25% of the 
results would be tainted by garbage collection and should be discarded. Therefore, an upper 
bound can be placed on the graph size to limit testing to graphs of this size otherwise excessively 
large data sets would need to be generated to ensure a reasonable sample size. 

Given these two facts then a bound is also implicitly placed on the number of edges for a 
biconnected graph between the minimum (where the edges form a Hamiltonian cycle and there 
are equal numbers of edges and vertices) and a maximal planar graph where there are (3V — 6) 
edges. 

The graph's structure can be considered, initially, in terms of 3-, 2- or 1-connected graphs: 

• 3-connected graphs have a unique embedding 1 and a particularly interesting sub-set of 
this family of graphs are the maximal planar graphs (simple planar graphs such that the 
addition of another edge to the graph makes it either non-simple or non-planar) 2 . Maximal 
planar graphs are particularly interesting as (a) the number of vertices is proportional to 
the number of edges (|£| = 3|V| — 6) and, since a maximal planar graph is biconnected 
then all leaves of the Tremaux Tree are cotree edges hence the number of cotree edges (and 
segments) is (2|V| — 5) (and proportional to the number of vertices); and (b) it is trivial 
to generate maximal planar graphs of increasing size. 

1 Corollary to Whitney's 2-Isomorphism Theorem [81, pg. 246]. 

2 All maximal planar graphs have a planar embedding on the surface of a sphere and, by using flat faces 
rather than following the surface of the sphere, is also the 1-skeleton of a convex polyhedron (3-dimensional 
convex polytope); by Steinitz's Theorem [27, Pg. 268] "A graph is 3-polytopal if and only if it is planar and 
3-connected.", it follows that maximal planar graphs are 3-connected. 
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• 2-connected (biconnected) graphs can be partitioned into two sub-categories 3 by consider- 
ing their minor graphs after coalescing each degree two vertex with an adjacent neighbour; 
the resulting minor is either 3- or 2-connected. 

— In the case that the resulting minor is 3-connected then the original graph has a 
unique embedding; and 

— In the case that the minor is 2-connected then at least one 2-separation exists and 
the embedding can be permuted via Whitney flip(s) to give alternate embeddings. 

• 1-connected (separable) graphs are not being considered for this purpose as a data structure 
representing all their possible embeddings does not appear to be able to be generated in 
linear time. 

Various abstract characteristics can also be considered: 

• Flips and permutations - since one of the important aspects of the algorithm is the ability 
to generate data structures representing all possible embeddings of a biconnected graph it 
is necessary to test graphs that permit multiple embeddings. By necessity, for a graph to 
exhibit flips or permutations then it cannot be 3-connected so some cases of 2-connected 
graph must be considered. 

• The variation in the degree of the graph's vertices - this presents two obvious extremes: 
when the variance in the vertex degree is as low as possible (and the vertices all have 
similar degrees); and when the variance in the vertex degree is higher and one or more 
vertices have a high degree and the rest have low degrees. Relating this to segments, then 
graphs with a vertex with high degree will have a large number of segments incident to 
that vertex 

• Another characteristic that can be considered is randomness - graph with specific 
properties will test those properties and, for the most part, only those properties; however, 
random graphs have the potential to highlight unknown issues. The converse is also true as, 
when specific properties are required (such as permutations in an embedding) it is difficult 
guarantee such a property through randomness without resorting to a large search space. 

From this four types for graph can be distilled: 

1. A graph with low variation in vertex degrees; 

2. A graph with high variation in vertex degrees; 

3. A graph with a range of vertex degrees; and 

4. A graph with random vertex degrees. 

Section 7.3 gives four maximal planar graph types: Triangular Prism (page 131); Planar Wheel 
(page 132); Ordered Face Trisection (page 133); and Random Face Trisection (page 134), that 
correspond to the types above as well as algorithms for their generation. These graph types are 
used throughout the chapter to test the algorithm's performance. 

As previously noted though, there is a need for biconnected graphs to test the performance of 
the algorithm when flippable blocks and permutable groups of segments are present. This can be 
achieved by removing edges from the graphs of the above types and, while this is likely to result 
in some flippable blocks, it is difficult to achieve an algorithm to remove edges in such a way as 
to leave pairs of segments that can be permuted (since those segments must have identical head 
and tail vertices and not conflict with either 's descendants). Therefore, there is an additional 
need to generate biconnected graphs that contain a permutable group of segments. 



Assuming that the graph being considered is not a Hamiltonian cycle. 
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The final two points for consideration relating to the algorithm's input are: the order in which a 
graph's edges are input to the algorithm; and the choice of root vertex. Both these factors affect 
the generation of the Tremaux Tree but, of the two, the edge order has the greater number of 
permutations and a much more subtle effect; since varying the order of -<* related edges does 
not affect the Tremaux Tree and it is only when the order of ||* related edges is varied that a 
different <** order (and, correspondingly, < s segment precedence order) occurs. Varying both 
these factors is counter-productive since they both produce similar effects and so attributing 
any changes would be difficult if both varied. Given this, then a determination was made to 
focus on changes in root vertex as this would always result in a different Tremaux Tree. 

Chapter 6 gives details of the some of the factors that affect benchmarking software in Java 
and how to mitigate against them. Putting together the requirements for different graph 
types and the methodology for implementing a benchmark lead to the construction of a test 
harness which is included in Appendix D.4.1 (page 344) and the timePlanarityTest method 
it references within the Graph class (Appendix D.2.3, page 279). This test harness identifies 
over 100 combinations of graph type, graph size and root vertex that test different aspects of 
the algorithm. 

The remainder of this chapter covers two main areas: 

1 . The properties of the graphs used in these benchmarks; and 

2. The analysis of the results obtained by executing these benchmarks. 
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7.3 Test Graphs 

The following section presents six methods for generating types of graphs designated as: 

• Triangular Prism Graphs; 

• Planar Wheel Graphs; 

• Ordered Face Trisection Graphs; 

• Random Face Trisection Graphs; 

• Permutable, Flippable Graphs; and 

• Sub-Graphs Generation via Non-Bridge Edge Deletion. 

The first two, Triangular Prism and Planar Wheel graphs, were chosen as they: 

• Are well-defined (the graphs can be built in a predictable, repeatable manner); 

• Are scalable (when a series of graphs of the same type and increasing size are compared 
then any smaller graph is a minor of a larger) ; 

• Are maximal planar (thus are triconnected and have a linear relationship between vertex-, 
edge- and segment-size); and 

• Have polar opposite characteristics relating to vertex degrees and maximum shortest path 
(as described in 7.3.7 on page 137). 

The third graph, designated as an Ordered Face Trisection Graph, is presented as a counterpoint 
to the previous two as it is also maximal planar and generated in a well-defined, scalable manner. 
However, compared to the previously mentioned graph types, the characteristics of the graph as 
graph size increases are not as simple to identify; for example, the frequency of vertex degrees 
does not follow a trivial pattern as graph size increases and the simple repeatable segment 
structures that are presented for the other graph types are not as readily apparent for this 
graph structure; therefore while the graph shows repeated structures it is difficult to show a 
repetitions in the structure associated with a linear increase in graph size. This is a useful 
counterpoint to the previous two graphs and tests the algorithm with a well-defined graph (so 
that the results are repeatable) but without the linear changes to the structure of the graph 
that are present in the other graph types. 

Random Face Trisection Graphs are also maximal planar but are generated in a random manner, 
in contrast to the well-defined manner that Ordered Face Trisection Graphs are generated in; 
this allows graph structures to be tested that might not otherwise be present in the previous, 
well-defined, graphs. 

The Permutable, Flippable Graph type is presented as a method of generating biconnected 
graphs which contain: a large group of segments which are permutable; and a large number 
of segments contained in flippable blocks (as the name suggests). These graphs are not 
maximal planar but they are well-defined, scalable and where the sub-graph generation algorithm 
discussed below may generate these properties it cannot guarantee it so this graph type aims to 
fill that void. 
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The final graph generation method considers non-maximal planar graphs - taking a graph of one 
of the previous four maximal planar types then generating a (scalable) series of connected sub- 
graphs of constant vertex- and decreasing edge-size can be generated via deletion of successive 
non-bridge edges from that graph; this allows for the generation of biconnected and separable 
graphs. By specifying an order to the selection of edges for deletion then the sub-graphs can be 
generated in a well-defined manner from any given super-graph. 
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7.3.1 Triangular Prism Graph 

The first graph presented is a Prism Graph [25] , given by the Cartesian Graph Product (C 3 x 
P^j ), extended with additional edges connecting sequential concentric triangles. When viewed 
in perspective with a central vanishing point then the graph appears to form a triangular prism. 

A triangular prism graph, of size N (where k — [yj , r — modulo(N,3) and i = min(l,r)), is 
formed of k concentric equilateral triangles of vertices and r additional vertices (either zero, one 
additional vertex at the centre or one vertex at the centre and one outside). The vertices are 
ordered in ascending numerical order from the centre spiraling outwards such that: 

• If i = 1, Vertex V\ is at the centre of the graph. 

• A radial line through vertex Vi+i also passes through V^+i, Vj+i, ■ ■ ., V^n.-i)-2+ii V 3 k-2+i', 

• A radial line through vertex V 2+t also passes through V 5+l , Vg+i, ■ ■ ., V3( fe _i)_i +i , V 3k -i+r, 

• A radial line through vertex V 3 +i also passes through V§+i, Vg+j, . . ., V 3 ^-i)+ii V 3 k+i', an d 

• If r = 2, Vertex V 3 k+2 is outside of the outermost concentric triangle on the radial line 
passing through V%. 

The edges are created in the order: 

1. For p = 2 . . . (3 + i), for q = 1 . . . (p - 1), 

(a) Edge (V q , V p ) is created. [Innermost A (and centre vertex if required)] 

2. For p = 2 . . . k 

( a ) (Vsp-2+i, V^p-i+i), (V3 p _2+i, Vsp+i), (V3 p _i+i, Vs p +i) 

[Edges forming the next concentric triangle] 

(b) (V 3p -5+i, V 3p -2+i), (Vap-3+i, Vip-2+i) [Connecting 1 st vertex of A to previous A] 

(c) (F 3p _4+i, V 3p - 1+ i), (V 3 p- 5+i , V 3p ^i +i ) [Connecting 2 nd vertex of A to previous A] 

(d) (y 3p _ 3+i , V 3 p +i ), (V3p_ 4 +i, V 3p+i ) [Connecting 3 rd vertex of A to previous A] 

3. If r = 2, (Vat-3, Vn), (V^-2, Vjv), (Vjv-i, Vn) [Connecting last vertex to previous A] 
This can be visualised as: 




(a) 6 Vertices (b) 9 Vertices (c) 10 Vertices (d) 11 Vertices 

Figure 7.3.1: Examples of Triangular Prism Graphs 



Triangular Prism Graphs have the following frequencies of vertex degrees: 



modulo(N, 3) 




Frequency of Vertices of: 




Degree 3 


Degree 4 


Degree 5 


Degree 6 








6 





N - 6 


1 
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3 


3 


TV — 7 


2 


2 





6 


N - 8 



Table 7.3.1: Vertex Degree Frequencies in a Triangular Prism Graph of size N . 
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7.3.2 Planar Wheel Graph 



This graph design is formed by three overlapping Wheel [25] Sub-Graphs (designated as W 1 , W 2 
and W 3 ). The graph can be described by: one central vertex (present in all wheel sub-graphs); 
three paths radiating from the central vertex (each path shared by two wheel sub-graphs); three 
hub vertices (unique to each wheel sub-graph) with connecting edges (spokes of the wheel) to 
the central vertex and each vertex of the two adjacent radial paths; and three edges, each unique 
to a wheel sub-graph and completing a cycle with two radial paths and the central vertex. 

For a planar wheel graph, of size N, the wheel sub-graph (W l ) comprises of (where i = 1 ... 3 
and j — modulo(i + 1,3) + 1): 

• The cycle of vertices 

(V u Vj. +3 y...,V^ | -i(Jf-D- | +1 ) , V( pXpL>] +i) . ■ ■ ■ » y ( |- »-i)Uv-ir | +3 ) ) ; and 

• The hub vertex V/ rc«-i)cw-i) i +2 ) 

The edges are created connecting, in the order: 
1. For i = 1...3: 



(a) Hub vertex V, 



( r-"f'" i+ 2 ) 



to the central vertex V\\ 



(b) Innermost spoke vertex V, 



(P 



(c) For j 



(i-l)(JV-l) 
3 



,)...( 



>l +3 ; 



i(N-l) 
3 



to the central vertex and the hub vertex; 



1 



i. The spoke vertex Vj to the previous spoke vertex Vj—\\ and 

ii. The spoke vertex Vj to the hub vertex. 

2. For i = 1 . . . 3, create an edge such that it joins: 

(a) The modulo(i, 3) + 1 th hub to each vertex in the i th spoke (from centre out); and 

(b) The vertices terminating the i th and modulo(i,3) + 1 th spoke. 

This can be visualised as: 




(a) 7 Vertices (b) 10 Vertices (c) 13 Vertices (d) 14 Vertices 

Figure 7.3.2: Examples of Planar Wheel Graphs 
Planar Wheel Graphs have the following frequencies of vertex degrees: 



modulo(N, 3) 
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Frequency of Vertices of Degree: 
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3 3 3 
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3 





N - 
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N - 
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1 
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1 



Table 7.3.2: Vertex Degree Frequencies in a Planar Wheel Graph of size N. 
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7.3.3 Ordered Face Trisection Graph 

This graph starts with a triangular cycle formed by three vertices and three edges creating an 
internal and an external face; this internal face is placed in a queue of faces. When a vertex is 
added to the graph: the face, at the head of the queue, is removed; the new vertex is placed 
at the centre of that face; that face is trisected by three edges connecting the vertices at the 
boundary of the face with the new vertex; and the three new (triangular) faces formed by this 
trisection are added to the tail of the queue of faces. 

The edges are created in the following order: 

1. The initial triangular face is created containing (in the order created): 

(a) Vertices Ui, v 2 and W3; and 

(b) Edges {vi,v 2 }, {v!,v 3 }, {v 2 ,v 3 }. 

2. Adding each successive vertex vk to the graph then the face at the head of the queue 
(containing vertices, in a clockwise order, va, vb and vc) will be trisected by the addition 
of edges {va,Vk}, {vb-,vk} and {vc,vk}) forming the faces containing (in the order 
appended to the queue and with vertices listed in a clockwise order) : 

(a) Vertices va, vb & Vk\ 

(b) Vertices vb, «c & vk', and 

(c) Vertices vc, va & vk- 

This can be visualised as: 




(a) 7 Vertices (b) 8 Vertices (c) 9 Vertices (d) 10 Vertices 



Figure 7.3.3: Examples of Ordered Face Trisection Graphs 



Unlike the previous two graphs, this graph does not have a trivial pattern to the frequency of 
vertex degrees. For graphs with N vertices, there will be: exactly [ 2jN ^~ 5 j vertices of degree 3 
(for N > 6); approximately |JV vertices of degree 6; approximately ~N vertices of degree 12; 
and, generally, approximately ^frN vertices of degree (3 x 2 fc ), where k E Nq. There may be 
individual vertices with degrees outside the previous pattern. For example, when N > 12, if 
modulo(N , 3) is then the graph contains one vertex of degree 4 but when the modulus is 1 
there exists one degree 5 vertex and when the modulus is 2 the graph will not contain any degree 
4 or 5 vertices; similar, but not as simple, patterns exist for vertices within the general range of 
degrees (3x2* + 1) through (3 x 2 k+1 - 1) for k > 2. 
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7.3.4 Random Face Trisection Graphs 

This graph starts with a triangular cycle formed by three vertices and three edges creating an 
internal and an external face; this internal face is placed in a (empty) array of faces. When a 
vertex is added to the graph: a face is removed from a random position in the array; the new 
vertex is placed at the centre of that face; that face is trisected by three edges connecting the 
vertices at the boundary of the face with the new vertex; and the three new (triangular) faces 
formed by this trisection are added to the array - one replacing the removed face and the other 
two faces added at the end of the array. 

Since faces are randomly selected for trisection then any pattern in the degrees of vertices as the 
graph size increases is coincidental to the order in which faces are created. This is a counterpoint 
to the previous types of graphs, which are created in a rigid manner and, correspondingly, have 
a distinct pattern to the structure of the graph and the degrees of the vertices. 

7.3.5 Permutable, Flippable Graphs 

A permutable, flippable graph, unlike the previous graphs is not maximal planar; instead it is 
designed to contain a group of permutable segments (permutable with the parent segment and 
containing its static child) and a number of flippable blocks. 

It can be constructed such that: 

• Vertices i>i, «2 and V3 are connected by edges {vi,V2} and {^i,^}; and 

• Each subsequent vertex v n is connected by edges {t>2, v n } and {v^, v n } and if (modulo (n, 2) = 
0) edge {«„_!,«„}. 

The graph appears similar to a gemstone where pairs of successive vertices (after the first three) 
form facets of the stone. Each facet (excluding the root segment) is composed of a parent 
segment, which is part of a permutable group of segments, and its descendants, which form a 
flippable block. 

For a permutable, flippable graph of n facets there are n '/2 permutations of segments (since one 
segment is static) and 2™ flippable blocks giving a total of n!2^" _1 ' possible embeddings of the 
graph. 

This can be visualised as: 




(a) 1 Facet (b) 2 Facets (c) 3 Facets (d) 4 Facets 



Figure 7.3.4: Examples of Permutable, Flippable Graphs 
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7.3.6 Sub-Graph Generation via Non-Bridge Edge Deletion 

The previous graph types (ignoring Permutable, Flippable graphs) have focused on maximal 
planar graphs and, as such, the number of vertices is proportional to the number of edges in each 
of those graphs. An algorithm to delete successive edges from a given (maximal planar) graph 
while maintaining that the graph remains connected gives a method of testing the performance 
of the planarity testing algorithm against graphs of a constant number of vertices but varying 
numbers of edges. 

Given a planar embedding T of graph S then any non-bridge edge e is contained in at 
least one cycle (lemma 4.1.19) and, by the Jordan Curve theorem [30, 39], is the boundary 
between two disjoint faces (/i and /2). Considering T\ {e} then the resulting set of faces is 
3 r u{/(i ! 2)} \ {/i, /2} where /(i,2) is the region (/iUeU/2). Repeated application of this operation 
results in the size of the edge- and face-sets (|£| and |5F|, respectively) reducing linearly and the 
size of the vertex-set (|V|) remains constant until there are no more non-bridge edges (when 
|V| = |£| + 1 and |5F| = 1). 

This leads to an algorithm to generate planar sub-graphs from a planar graph given a Tremaux 
Tree of that graph. Removal of any non-bridge (tree or cotree) edge is such that: 

• If the removed edge is a cotree edge then a leaf of the Tremaux Tree has been removed and 
the relative precedence of the other elements of the Tremaux Tree is unaffected; however, 

• If the removed edge is a tree edge then the Tremaux Tree is partitioned into two disjoint 
tree structures (containing those elements succeeding and not succeeding that tree edge); 
these can be reconnected by re-designating a cotree edge, connecting the disjoint parts, as 
a tree edge and refactoring the precedence of the elements within the Tremaux Tree. 

Different sequences of successively smaller sub-graphs can be achieved by varying the 
selection and order in which non-bridge edges are removed; since, if necessary, the Tremaux 
Tree is re-factored at each step then only the existence of bridge edges restricts the choice 
for which edge is removed and the choice of initial spanning tree does not affect this. 

Considering the relationship between the number of segment and edges: each segment contains at 
least one edge (assuming the graph does not consist of a single vertex) ; therefore, the maximum 
bound on the number of segments is equal to the number of edges; however, the number of 
segments will only equal the number of edges if every edge is either a looping edge or a bridge 
edge outbound from the root vertex. Therefore, for most graphs, the number of segments is less 
than the number of edges. 

Considering the deletion of a non-bridge edge (u — > v) where a single leaf of the Tremaux Tree 
is reachable from vertex u then, it follows that, that leaf must be a cotree edge and can be 
designated (x-^>y) (where y =4 u -< (u^v) =4 (x^>y)), and: 

• If (u — »• v) = [x y) then, post-deletion, u becomes a leaf of the Tremaux Tree and the 
number of leaves remains constant while the number of edges decreases; 

• Otherwise (u4«) is a tree edge and, post-deletion, the Tremaux Tree is re-organised 
such that (a; y) is re-designated as a tree edge and the direction of all edges which 
had previously succeeded v are reversed so v becomes a leaf of the Tremaux Tree so, at 
a minimum, the number of segments remains constant. If, in this case, y < u then, post- 
deletion, as well as the re-designated path to v there exists a path of tree edges from y to 
u and so the number of segments will increase by one as the number of edges decreases. 
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Therefore, edge deletion does not necessarily reduce the number of segments by one and in some 
cases can, if the deleted edge is a tree edge, increase the number of segments. 

The simplest method of generating graphs by edge deletion is to always remove cotree edges 
from the embedding until only tree edges remain and the graph is reduced to a spanning tree. 
In this case: 

• Each deletion does not increase the number of segments; and 

• The choice of initial spanning tree restricts the edges that can be removed; however, this 
can be mitigated against by (a) selecting a different root vertex 4 , allowing limited variation 
in the Tremaux Tree, or (b) changing the order in which edges are processed by the DFS 
algorithm generating the Tremaux Tree and, hence, the Tremaux Tree structure itself. 

Biconnected Sub-Graph Generation via Non-Bridge Edge Deletion 

In a similar vein to generating connected sub-graphs, biconnected sub-graphs can be generated 
through careful choice of edges for deletion. 

Considering each cotree edge (u -2> v) then two cases can be considered: 

1. When it is the sole edge within a segment - in this case, if the original graph was 
biconnected then a cotree edge (u i>) must form a Class 4 segment and so has a parent 
segment which forms a cycle (of itself or with ancestors) which contains both u and v; 
therefore, deletion of (u -2> v) does not make the sub-graph separable. 

2. When it is not the sole edge within a segment - in this case, if the original graph was 
biconnected and the containing segment has a descendant outbound from u (hence u 
would not be reduced to a degree of 1 ) then it may be possible to delete (u-^rv). 

Assuming (u v) is contained in segment s of a biconnected graph then if there exists a 
descendant of s outbound from u which is either: inbound to a vertex preceding s's head 
vertex; or is in a block which contains another descendant of s which is inbound to a vertex 
preceding s's head vertex, then there exists a cycle containing all other elements of s and 
some elements of s's parent; therefore deleting (u v) will not induce a 1-separation in the 
graph. However, if there exists no descendant of s with either property then all descendant 
segments outbound from u are in flippable blocks (which do not contain segments inbound 
to v) and so deleting (u w) would induce a 1-separation in the graph. 

This second case requires both an embedding of the graph and a test of descendant segments and, 
if successful, would result in the segments and segment hierarchy being reorganised; therefore it 
is not the most efficient approach (more efficient methods may exist but that is not the focus of 
this work). 

Therefore, a simple and efficient method of generating a biconnected graph from a 3-connected 
graph is to delete only cotree edges where they are the sole edge of their segment. This is used 
within ReduceableBiconnectedGraphGenerator . java (section D.3.7) to generate biconnected 
graphs of the four previous maximal planar graph types and these sub-graphs are used within 
the empirical testing later in this chapter (section 7.6, page 159). 



4 This can be seen in 10 vertex Planar Wheel graphs with root of 1 st (figure 7.3.7a) or 10 th (figure 7.3.8a) vertex; 
edge {8, 9} is a tree and a cotree edge for those respective graphs. 
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7.3.7 Comparison of Test Graph's Properties 



The test graphs have, for a graph of size TV, the properties shown in Table 7.3.3. 



Property Triangular Prism Planar Wheel 



Ordered Face 
Trisection 



Random 
Face 

Trisection 



Number of Maximal Planar Maximal Planar Maximal Planar 
Edges (37V -6) (37V - 6) (37V — 6) 



Modal 

Vertex 6 (when TV > 14) 4 (when TV > 10) 3 (when TV > 8) 
Degree 

Vertex 2^/6(N-6) V4jV 3 -80iV 2 +454jV-432 

Degree Std. 3 , \ o(VN)* O (V W • log 2 (TV)) 



Deviation —< ^(vjv) 
Maximum 

Vertex 6 = 0(1) 
Degree 



Maximal 
Planar 
(3TV - 6) 

Random 



6 Random 



2N-3 



= 0(N) 



Maximum , N , , , ... „. 

Shortest W+modulo(TV,3) g = 



0(JV) 

0(lo g2 (TV)) 



O(N) 
O(N) 



Table 7.3.3: Comparison of Test Graph Properties 



The triangular prism graph has: 

• A constant maximum vertex degree; 

• Decreasing standard deviation in the degree of the vertices; and 

• A linearly increasing maximum shortest path between pairs of vertices. 

Whereas the planar wheel graph has: 

• A linearly increasing maximum vertex degree; 

• Increasing standard deviation in the degree of vertices; and 

• A constant maximum shortest path between pairs of vertices. 

Comparing these attributes shows that the two graphs are diametrically opposite in their features 
and represent two different extremes in structures. The characteristics of the ordered face 
trisection graph are part way between both extremes; whilst the random face trisection graph 
is maximal planar, the same as the other types, but has no set properties. 



5 When modulo (AT, 3) = 1; for other graph sizes u = V 4JV 80 ^^_ 438iv 432 , 

6 Mean vertex degree (x) is (6 — ^). 

There are approximately 3 ( fc +i) N vertices of size (3 • 2 fe ) for k = . . . |^log 2 yj . 



(§)*2* 



x 2 < V 6 E 



4^2 fj 



< ^6 (log 2 f + l)2( lo ^f) _ 5 2 < j 2N (log 2 7V + 1 - log 2 3) - (6 - f ) 2 = 0(y/N ■ log 2 7V) 
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7.3.8 Scalability of Test Graphs 



An algorithm for generating graphs is classed as being scalable when two graphs of different size 
can be generated and the smaller graph is a minor of the larger. For two graphs of the same 
type, generated using one of the previously listed algorithms (and assuming, for Triangular 
Prism Graphs, that only full concentric triangles are considered and any central vertex or single 
vertex in the outer face is ignored), then the graphs are generated such that the smaller graph 
is always minor of the larger; hence, those graphs can be classed as being scalable. 

This property can also be investigated using the hierarchy of the segment tree and the 
composition of those segments: Figures 7.3.7 through 7.3.10 show the segment structures for 
various graph sizes, types and root vertices; displaying the segments in < s precedence order 
and indented to highlight their parent-child relationships. Individual segments are displayed as 
a bracketed list of vertices starting from the segment's head vertex and terminating at its tail 
vertex. 

Looking at the graph types and root vertex combinations shows some simple patterns as to how 
the segment structure evolves: 

• The simplest graph segment structure to consider is a Triangular Prism Graph where the 
root is the 1 st vertex (figure 7.3.5); as successive triplets of vertices are added to the graph, 
the graph's segment structure is a duplication of the segment structure for previous graphs 
in the sequence with the additional segments, created as the graph size increases, appended 
to the deepest point of the segment tree. As an aside, for this graph type and root vertex, 
this means both the mean and maximum segment depths are approximately linear with 
the graph size. 

• In contrast, a Planar Wheel Graph where the root is the last vertex (figure 7.3.8) has a 
segment tree of constant maximum depth as graph size increases. With each triplet of 
vertices (and corresponding nine edges) added to the graph: the number of vertices and 
edges in the first three segments of the hierarchy increases by one; and the remaining six 
edges all form segments composed of a single cotree edge which are appended in the ratio 
1:1:2:2 over, respectively, the 2 nd through 5 th levels of the segment tree. The average 
segment depth for this graph type and root is, given this progression and N vertices, 



• For a Planar Wheel Graph with 1st vertex as the root (figure 7.3.7): the 2 nd and 4 th 
segments increase in length by one vertex (and edge); the remaining vertex (and two 
edges) forms a new segment which is appended to the penultimate level of the segment 
tree, increasing the depth of the tree by one; a new single cotree edge segment is added as 
a sibling on that penultimate level; and the two pairs of single cotree edge segments are 
appended at depth two and three in the segment tree. 

• A Triangular Prism Graph with the last vertex as root (figure 7.3.6) is similar to when 
the 1st vertex is the root as segments are appended, in groups, to the deepest segment; 
however, in this case, the deepest segment is in the middle of the list of segments. From 
the base structure, recursively, a segment of 3 vertices is added then descending from it 
a segment of 4 vertices and four segments containing only frond edges (2 vertices) ; when 
the graph size increases by three again then the same structure is added again descending 
from that length 4 segment in the middle of the four length 2 segments. 

• The two root vertices shown for the Ordered Face Trisection Graphs (figures 7.3.9 and 
7.3.10) both display repeated structures; in particular, when the root is the first vertex 
then there are groups of segments with depth of 3 which have same structure as the graph 




CHAPTER 7. EMPIRICAL TESTING 



139 



size increases. However, the segment structure is not as easily denned as the other two 
graph types. 

The examples presented are minimal examples, able to be visualised on a single page, and 
scaling this to larger graphs is impractical to visualise within the constraints of this document; 
however, it should be noted that similar patterns within the segment structure are present for 
different root vertices (where the root vertex is chosen as a constant fraction of the total graph 
size) when the graph sizes increase beyond these minimal examples. The next section gives 
empirical evidence supporting this claim by comparing the execution time of the algorithm with 
variation in the root vertex and demonstrating similar patterns in execution time as the graph 
size increases. 
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7.4 Empirical Testing using Different Root Vertices 

The previous section gives some simple examples of how the segment structure varies as the 
graph size, structure and choice of root vertex varies. This section expands on the 



10D0 Vertex Triangular Prism Graph 



♦ 75-1 0D lh %ile Data 

♦ 50-75" 1 %ile Data 

• 25-50 lh %ile Data 

• 0-25 lh %Ile Data 




100 200 300 



400 500 BOO 

Root Vertex ID 



700 800 900 



Figure 7.4.1: Execution Times for Varying Root Vertices of 1000 Vertex Triangular Prism 
Graph 



Figure 7.4.1 shows the full data-set from executing the algorithm over a 1000 vertex Triangular 
Prism Graph and varying the root vertex. The algorithm was executed 1000 times for each root 
vertex (shown along the x-axis using the sequential numerical id assigned to each vertex as it is 
created) and the duration of the execution records (y-axis) ; the execution times are displayed in 
coloured quartile bands so that the quartile boundaries and interquartile range can be visualised. 
Several points can be noted regarding the data: 



1. The majority of the data is in a band between 8-9. 5ms that decreases as the Id assigned to 
each root vertex increases; however, there are scattered outlying data points up to 100% 
above this range. 

2. There are two distinct curves in the data set that converge as the root vertex Id increases 
such that: one curve starts (at the lower root vertex id) at median of ~8.9ms; the starts 
other at ~8.45ms; and both curves decrease to a median of ~8.25ms. 



Examining this last point: Vertex ids are assigned in the order that those vertices are created 
by the algorithm generating the graph and, as such, is an arbitrary numerical value where the 
relative order is not particularly significant. For a Triangular Prism graph, the graph generation 
algorithm creates vertices in successive concentric triangles and assigns the vertex id spiraling 
out from the centre; instead, the vertices can be partitioned into three groups, separated on 
modulus 3 of their vertex id, representing vertices on a spoke of the graph radiating from its 
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centre and within those partitions can be re-assigned vertex ids corresponding to increasing 
distance from the centre. This can be achieved using the mapping x i— > \(N-modu\o(x,?,)+x)/^^ 
where N is the number of vertices in the graph and x is the default vertex id assigned during 
generation. 

x -|o 6 1000 Vertex Triangular Prism Graph (98th Percentile) 



■ 


75-98 th %ile Data 


■ 


50-75 th %ile Data 


■ 


25-50 th %ile Data 


■ 


0-25 th %i le Data 




_y=+8439245.8619 




(Robust Regression, MAE = 151689) 




_ y=1 257.5338f(x)+81 01 857.8223 




(Robust Regression, MAE = 135746) 




100 200 300 400 500 600 700 800 900 1000 

Root Vertex ID (Mapped) 

Figure 7.4.2: Execution Times for Varying Root Vertices of 1000 Vertex Triangular Prism 
Graph (98 th %ile Data, Mapped Root ID) 

Figure 7.4.2 shows the same data where: 

• The vertex id of the root has undergone this mapping, clearly displaying the difference 
between the two curves; and 

• The data above the 98 th percentile has been removed for each vertex id; this eliminates 
the outlying higher execution time data points which significantly reduces the range of 
execution times being displayed and allows the lower quartiles to be more easily visualised. 

Two best-fit curves were also investigated: a constant best-fit; and a best-fit of the mean depth 
of the segments within the segment tree (shown in dark green and red, respectively, in figure 
7.4.2). These two best-fits were chosen as they allow a simple comparison between whether the 
execution time of the algorithm is affected or unaffected by variations in the structure of the 
segment tree as the root vertex changes. 

The fits were calculated using iteratively re-weighted least squares and the constant execution 
time fit has Mean Absolute Error (MAE) of 151689 whereas the mean segment depth fit has 
MAE of 135746. The lower MAE indicates a better fit to the data, suggesting that changes to 
the composition of the segments and the structure of the segment tree influences the execution 
time. However, visual inspection shows that while the mean segment depth fit follows the data 
when the root vertex is closer to the centre (towards the left of each of the three partitions in 
figure 7.4.2) as the root vertex reaches ~ 2 /3 of the way towards the outer triangle of vertices the 
mean segment depth starts to rise, diverging from the data, indicating that it does fully model 
the execution time of the algorithm as the root vertex varies. 
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Expanding this to look at how varying the root vertex for Triangular Prism Graphs of different 
sizes affects execution time: appendix A contains figures A. 1.1 - A. 1.5 which show the empirical 
testing results for varying root vertex of (respectively) 250, 500, 750, 1250 and 1500 vertex 
Triangular Prism Graphs. These graphs show: 

• Each graph shows a similar pattern of after mapping the vertex id such that the partitions 
of vertex ids show two approximately identical higher curves and one lower curve; 

• The lower curve is in the middle partition of the vertex ids when modulus 3 of the number 
of vertices is zero (when there is no central vertex) and is in the right partition otherwise 
(when there is a central vertex) ; 

• The shape of the mean segment-depth best-fit curve is similar as the graph size varies 
suggesting that the structure of the segment tree may be similar as the graph size increases; 
and 

• Table 7.4.1 shows the MAEs for both mean segment-depth and a constant best-fit and, in 
all cases, the lower MAE (highlighted in green) is for the mean segment-depth best-fit. 



Number of 
Vertices 


MAE for 
Constant Fit 


MAE for 
Mean Segment 
Depth Fit 


Figure 


250 


19615 


16692 


A.l.l 


500 


71988 


54032 


A.1.2 


750 


118765 


100171 


A.1.3 


1000 


151689 


135746 


7.4.2 


1250 


196180 


180767 


A.1.4 


1500 


240885 


221861 


A.1.5 



Table 7.4.1: Mean Absolute Error for Best-Fit Curves to Triangular Prism Results with 
Varying Root Vertices 
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Figure 7.4.3: Execution Times for Varying Root Vertices of 1000 Vertex Planar Wheel Graph 
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Figure 7.4.3 shows the empirical testing results for a 1000 vertex Planar Wheel graph (unmapped 
and showing the 98 th percentile results so the upper quartile does not excessively dominate the 
range of results). The plot shows these properties: 

• Similar to the results for Triangular Prism graphs, the plot shows three groups of results 
corresponding to each of the three radial lines of vertices emanating from the centre of the 
wheel graph. 

• The left-most two groups both show an approximately linear increase in execution time as 
the root vertex is further away from the centre. 

• The right-most group shows a non-linear decrease as the root vertex moves further along 
that radial line of vertices away from the centre. 

• The execution times for the hubs of the three wheels (at vertices 2, 335, & 668) show a 
marked increase compared to the results for the radial lines of vertices (although this is 
partly obsucred by the mean segment-depth best-fit). 

• There is an unusual spray of results for vertices with ids between 500 and 550 - after 
repeating the execution of this test this spray disappears (although other similar anomalies 
appear in other locations) suggesting that it is the impact of an external event on the 
benchmark and not a factor of the graph structure. 

• The mean segment-depth best-fit for the left-most two groups of vertices is almost 
horizontal but has a slight downward trend, in contrast to the empirical results. 
Additionally, the outer-most vertex in each of these groups shows a drop in the mean 
segment-depth compared to the relatively constant values within the rest of the group of 
vertices and this drop is not present in the empirical testing data. 

• The mean segment-depth best-fit for the right-most group of vertices shows a similar 
downward trend to the empirical data. 

• The mean segment-depth best-fit at the hubs of the three wheels (at vertices 2, 335, & 668) 
show spikes in the depth of the segment tree that correspond to the increased execution 
time present in the empirical testing results. 

Appendix A contains figures A. 1.6 - A. 1.10 that show the empirical testing results for 250, 
500, 750, 1250 and 1500 vertex Planar Wheel Graphs that display similar features in both the 
execution time and for mean segment-depth. Table 7.4.2, below, lists the MAE between each 
best-fit curve and the empirical data and, in all cases, shows that the lower (highlighted in 
green) value corresponds to the mean segment-depth indicating that it provides a better fit to 
the data than a constant value. 
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MAE for 


MAE for 


Figure 
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Constant Fit 


Mean Segment 








Depth Fit 




250 


35167 


16282 


A.1.6 


500 


89653 


38959 


A.1.7 


750 


97213 


51124 


A.1.8 


1000 


166985 


75280 


7.4.3 


1250 


176922 


75365 


A.1.9 


1500 


224613 


80791 


A.1.10 



Table 7.4.2: Mean Absolute Error for Best-Fit Curves to Planar Wheel Results with Varying 
Root Vertices 
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Figure 7.4.4. below, shows the empirical testing results for a 1000 vertex Ordered Face Trisection 
graph (unmapped and showing the 98 th percentile results so the upper quartile does not 
excessively dominate the range of results) . Unlike the previous two graphs there is not a distinct 
pattern to either the empirical testing results nor the mean segment-depth as both are relatively 
constant across the domain of vertex ids; however, the mean segment-depth best-fit does have 
a marginally lower MAE when compared to the constant best-fit. 

Appendix A contains figures A. 1.11 - A. 1.16 showing empirical testing results for 250, 500, 750, 
1250, 1500 and 2000 vertex Ordered Face Trisection Graphs which display similar features to 
the 1000 vertex graph in both the execution time and for mean segment-depth. Table 7.4.3, 
below, lists the MAE between each best-fit curve and the empirical data and, in all cases, shows 
that the lower (highlighted in green) value corresponds to the mean segment-depth indicating 
that it provides a better fit to the data than a constant value; however, as noted for the 1000 
vertex graph, this improvement is marginal in all cases. 
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Figure 7.4.4: Execution Times for Varying Root Vertices of 1000 Vertex Ordered Face 
Trisection Graph 
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250 


14947 


14944 


A.l.ll 


500 


78655 


78646 


A.1.12 


750 


44280 


44077 


A.1.13 


1000 


42249 


42166 


7.4.4 


1250 


46152 


46049 


A.1.14 


1500 


140520 


140420 


A.1.15 


2000 


281160 


281100 


A.1.16 



Table 7.4.3: Mean Absolute Error for Best-Fit Curves to Ordered Face Trisection Results with 
Varying Root Vertices 
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1000 Vertex Random Face Trisection Graph (98th Percentile) 

• 75-98 1 " %ile Data 
50-75 1 " %ile Data 

• 25-50 1 " %ile Data 

• 0-25 th %ile Data 
y=+7739621.5916 

(Robust Regression, MAE = 672643) \ 

y=249.2045f(x)+7737524.6073 

(Robust Regression, MAE = 672644) 
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Figure 7.4.5: Execution Times for Varying Root Vertices of 1000 Vertex Random Face 
Trisection Graph 



Figure 7.4.5 shows the empirical testing results for a 1000 vertex Random Face Trisection graph 
(unmapped and showing the 98 th percentile results so the upper quartile does not excessively 
dominate the range of results). Similar to Ordered Face Trisection graphs, there is not a distinct 
pattern to either the empirical testing results nor the mean segment-depth as both are relatively 
constant across the domain of vertex ids; however, in contrast to the previous cases, the constant 
best-fit has a the lower MAE compared to the mean segment-depth best-fit but the difference 
is minimal. 

The plot shows a series of increases (of a factor of -2.1) in the execution time at approximately 
regular intervals. Repeating the benchmark with a reduced number of repetitions (Figure 7.4.6 
- where the second result-set is displayed in blue-green overlayed with the previous result-set in 
black-red), on page 149, also shows a pattern of outlying results, however, the outliers are not in 
the same locations suggesting that these increases are not related to the structure of the graph 
or the implementation of the algorithm but instead due to an external factor. 
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1000 Vertex Random Face Trisection Graphs (98th Percentile) 
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Figure 7.4.6: Two Overlaid Result-Sets for Execution Times for Varying Root Vertices of the 
Same 1000 Vertex Random Face Trisection Graph 

Figure 7.4.7, below, shows the same data as in figure 7.4.5 with the execution time cut off at 
8.1ms (removing the increased results from the visualisation; still showing 98 th percentile data) 
and this highlights that the execution time as the root vertex is varied is approximately constant. 
Using this thresholded data, the mean segment-depth has a lower MAE than a constant best-fit 
but there is still no significant difference between the two fits. 



1000 Vertex Random Face Trisection Graph (98th Percentile) 



75-98'" %ile Data 

50-75 1 " %ile Data 

25-50 1 " %ile Data 

0-25 lh Voile Data 

y=+ 7738496.1784 

<Robust Regression, MAE = 41709) 

y=241 .8502f(x)+7736430.6603 

<Robust Regression, MAE = 41705) 



fj! 



400 500 

Root Vertex ID 



Figure 7.4.7: Execution Times for Varying Root Vertices of 1000 Vertex Random Face 
Trisection Graph (Results for Execution Times < 8.1ms) 
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Appendix A contains figures A. 1.17 - A. 1.21 showing empirical testing results for 250, 500, 750, 
1250 and 1500 vertex Random Face Trisection Graphs which display similar features, to the 1000 
vertex graph in figure 7.4.5, in both the execution time and for mean segment-depth. These 
graphs all show outlying periods of increased execution time as the root vertex varies: 

• The outlying results are, for all graph sizes, a factor of, approximately, 2.1 compared to 
the majority of the result; and 

• These periods are approximately regular. However, in the case of the 250 vertex graph 
they are not present initially. 

Table 7.4.4, below, lists the MAE between each best-fit curve and the empirical data and shows 
that, in all cases, the fits have approximately the same error (which is unsurprising since the 
mean segment depth is approximately constant for all root vertices); however, with the exception 
of the 1000 vertex graph, there is a marginal trend towards the mean segment depth providing 
a better fit than a constant value. 



Number of 
Vertices 


MAE for 
Constant Fit 


MAE for 
Mean Segment 
Depth Fit 


Figure 


250 


100973 


100968 


A.1.17 


500 


262696 


262693 


A.1.18 


750 


476618 




A.1.19 


1000 


672643 


672644 


7.4.5 


1250 


773620 


773615 


A.1.20 


1500 


1022384 


1022313 


A.1.21 



Table 7.4.4: Mean Absolute Error for Best-Fit Curves to Random Face Trisection Results 
with Varying Root Vertices 

7.4.1 Conclusions for Varying Root Vertex for a Constant Graph Size 
and Structure 

Two main conclusions can be drawn, regarding the mean segment depth, from the empirical 
testing of varying the root vertex used in the planarity testing whilst keeping the graph constant. 

1. The results indicate that the mean segment depth typically gives a better (or at least 
as good as an) approximation, when compared to a constant value, when considering 
the variation in execution time with root vertex. However there is not a direct mapping 
from mean segment depth to execution time; as is evidenced by the triangular prism 
(figure 7.4.2) and planar wheel (figure 7.4.3) graph types where the mean segment depth 
demonstrates some attributes of the corresponding execution time results but there are 
also attributes which are not present. 

2. The shape of the curves generated by the empirical testing and for the mean segment 
depth is similar as the graph size increases. Thus if a graph exhibits a characteristic at a 
given root vertex id (as assigned during generation) then as the graph size changes that 
same characteristic is present at a root vertex id which is proportional to the change in 
graph size. 

Both of these suggest that graphs of the same type have similar structures to their segment 
hierarchies as their size increases. 

The results also indicates that as a graph's size increases, for a given graph type, then the 
execution time of the planarity testing algorithm also increases. This result is explored further 
in subsequent sections of this chapter. 
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7.5 Empirical Testing on Maximal-Planar Graphs of Vary- 
ing Size 

This section considers the effect on execution time of the planarity testing algorithm (testing 
for planarity and generating a cyclic edge order) when, for maximal planar graphs of a similar 
structure, the graph's size is increased and the root vertex is constant (proportional to the graph 
size). The types graphs considered are: triangular prism; planar wheel; ordered face trisection; 
and random face trisection - representing maximal planar graphs with different properties. 

Figure 7.5.1, below, shows the results of (up to) 1000 repetitions 7 for each triangular prism 
graph with size from 42 vertices up to 4500 vertices, in increments of 3 vertices, where the 
root vertex is the graph's first (central) vertex. Four curves are overlaid on the graph showing 
the best-fits from the empirical testing results to y — ax + b (red) , y = ax ■ In (x) + b (green) , 
y = ax ■ In (In (x)) + b (blue) and to the mean segment depth (purple - shown as y = a ■ f (x) + b 
in the legend); these curves overlap in the figure so the pertinent information relating to the 
curve is included in the legend, including the MAE (where the lowest MAE indicates the closest 
fit to the data) . 



Triangular Prism Graph (Root = 1st) 




y=1 8537.01 45f(x)-705825.4024 

(Robust Regression, MAE = 269797) 

_*! I l l l l l l l l l 

500 1000 1500 2000 2500 3000 3500 4000 4500 

Number of Vertices 

Figure 7.5.1: Triangular Prism Graph (42-4500 Vertices, 1 st Vertex Root) 

These best-fit curves show several properties: 

• The lowest MAE is for a linear best-fit; however the mean segment depth has an almost 
identical MAE (which is unsurprising since, in this case, the mean segment depth is almost 
linear) . 

• The y-intercept of the linear best-fit is negative and the results for small graph sizes 
diverges from the linear fit to tend towards an execution time of zero (rather than an 
impossible negative execution time). It should be noted that a similar result was achieved 
for Hopcroft and Tarjan's algorithm where their test results indicated an execution time 
of T = .0125V - .07 [32, Pg. 565]. 

7 Repetitions interrupted by garbage collection are excluded from the results. 
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Table 7.5.1 shows the MAEs for the best-fits for empirical testing on graphs where, for a graph 
with N vertices, the root vertex is the 1 st , l /iN tl1 , !/2iV th , 3/ 4 7V th and N th vertex. The figures 
associated with these results are included in Appendix A. 2.1 (with the exception of figure 7.5.1 
which is included above) . All these results are comparable to results when the root vertex is at 
the minimum such that: 

• The lowest MAE for each results-set is for a linear best-fit (with the exception when the 
root vertex is at 1/2 of the graph size, in which case, the lowest MAE is for the mean 
segment depth); however, in all cases, the mean segment depth and linear curves have 
almost identical MAEs (since the mean segment depth is approximately linear). 

• The y-intercept of the linear best-fit for all these results-sets is negative. 

The results-sets where the root vertex is the: 

• !/4iV th vertex shows a small "blip" in the results for graphs of small size (42-200 vertices) 
but is otherwise linear. 

• 1 /2N th vertex shows a series of outlying results occurring at approximately regular time 
intervals (which appears at decreasing graph size intervals) where the outliers demonstrate 
an increase of a constant factor compared to the linear best-fit. 

• 7V th vertex shows a similar series of outlying results; however, the outliers initially occur 
regularly and then at greater intervals until they disappear. 

Subsequent benchmarks (table 7.5.2, below) show some of the same combinations of graph type, 
size and root vertex but show different patterns of outliers (also a constant factor above the linear 
best-fit), within the same range of graph sizes, suggesting that these occurrences are indicative 
of an intermittent external event interrupting (or sharing a processor with) the planarity test 
rather than being symptomatic of the graphs or the algorithm. 
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269794 


473650 
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7.5.1 


1/4N 


266796 
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321899 
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A.2.1 


1/2N 


2667103 


2856678 


2710051 


2667039 


A.2.2 


3/4N 


229296 


437942 


287909 


229311 


A.2.3 


N 


438760 


645159 


495399 


438763 


A.2.4 



Table 7.5.1: Mean Absolute Error for Best-Fit Curves to Triangular Prism (42-4500 Vertices) 
Results 



Table 7.5.2 shows the MAEs for the Triangular Prism graphs with the same root vertices as 
above but with graph sizes of 500-15000 vertices. Similar to above, the MAE indicates that a 
linear best-fit gives the best approximation to the results-set for each case of root vertex. Also, 
these results all have intermittent outliers which appear at approximately regular time intervals; 
as already noted above, these outliers appear for different graph sizes to the 42-4500 vertex 
benchmarks which implies that the outliers are not related to the graphs or the algorithm. 
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5953757 
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1 A.2.5 


1/4N 


10828822 


11378716 
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10828827 


A.2.6 


1/2N 
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A.2.7 
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11271872 


A.2.8 


N 


7837889 


8233416 
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7837889 


A.2.9 



Table 7.5.2: Mean Absolute Error for Best-Fit Curves to Triangular Prism (500-15000 
Vertices) Results 
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Figure 7.5.2, below, shows the results of (up to) 1000 repetitions (results interrupted by garbage 
collection are excluded) for each planar wheel graph with size from 42 vertices up to 4500 
vertices, in increments of 3 vertices, where the root vertex is the graph's first (central) vertex. 
Again, four curves are overlaid on the graph showing the best-fits from the empirical testing 
results to y = ax + b (red), y = ax ■ In (x) + b (green), y — ax ■ In (In (x)) + b (blue) and to the 
mean segment depth (purple - shown as y = a ■ f (x) + b in the legend). 

Several properties can be noted: 

• Similar to the results for Triangular Prism graphs, the results show a series of intermittent 
outliers; these appear part way through the results-set (from graphs of ~2700 vertices) and 
from then occur at approximately regular time intervals; 

• The linear and mean segment depth best-fit curves are almost identical and, correspond- 
ingly, have similar MAEs; and 

• The MAEs for the best-fit curves indicates that y = ax ■ In (x) + b provides the best 
approximation to this results-set. 




Figure 7.5.2: Planar Wheel Graph (42-4500 Vertices, 1 st Vertex Root) 



Table 7.5.3, below, shows the MAEs for that figure and for the results-sets of other root vertices 
for Planar Wheel graphs of 42-4500 vertices. 
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Table 7.5.3: Mean Absolute Error for Best-Fit Curves to Planar Wheel (42-4500 Vertices) 
Results 
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In all cases, these results show: 

• The best approximation to the curve is not given by a linear best-fit. 

• There are outlying results which are a constant factor above the main body of results. 

Examining the reason for the apparent non-linearity, table 7.5.4 shows the same result-sets with 
the tiny graph sizes excluded from the analysis. In these cases, the MAEs all indicate that the 
results-sets are best approximated by a linear fit and it is only the inclusion of graphs with a 
small (< 750) number of vertices which distorts these results. As previously noted for Triangular 
Prism graphs, the y-intercept of the linear best-fit is negative (as is the case here); thus the linear 
trend cannot be followed for these small graph sizes else they would have a negative (impossible) 
execution time. 
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A.2.20 



Table 7.5.4: Mean Absolute Error for Best-Fit Curves to Planar Wheel (Up to 4500 Vertices) 
Results After Removal of Tiny Graph Sizes 

One additional point that can be made about these results. Table 7.5.3 shows the MAEs for the 
results-sets for different root vertices and in all cases, except for graphs of N vertices when the 
root vertex is the N th vertex, the MAE for the linear fit and the mean segment depth fit are 
approximately equal (since the mean segment depth is approximately linear). In the exception, 
the mean segment depth is not linear; instead (as noted in section 7.3.8, on page 138) as the 
graph size increases the mean segment depth tends towards 23 /e and the mean segment depth 
best-fit has an MAE an order of magnitude above the other best-fits. 

Therefore, where mean segment depth has provided some limited insight into how the execution 
time changes as the graph size is constant and the root vertex varies - this does not follow 
into the case where the graph size is varied and the root vertex is constant (proportional to the 
graph size). It has only appeared that way for the previous results as, coincident ally, the mean 
segment depth has increased approximately linearly with graph size. 
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Table 7.5.5: Mean Absolute Error for Best-Fit Curves to Planar Wheel (500-15000 Vertices) 
Results 



Table 7.5.5 shows the MAEs for the same root vertices of 500-15000 vertex Planar Wheel graphs. 
In all cases, the MAEs indicate that the best approximation to the results-sets is given by a 
linear fit and or by the mean segment depth fit when it is, correspondingly, linear. 

It can also be noted, that each of those results-sets shows outliers to a greater ( 1 /2N th root) 
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or lesser (1 st root) degree but at different points to the previous results sets for 42-4500 vertex 
Planar Wheel graphs. 

x -I0 7 Ordered Face Trisection Graph (Root = 1st) 

10 r 



8 - 




(Robust Regression, MAE = 5008230) 

4 I I I I I I I I I I 

500 1000 1500 2000 2500 3000 3500 4000 4500 

Number of Vertices 

Figure 7.5.3: Ordered Face Trisection Graph (42-4500 Vertices, 1 st Vertex Root) 

Figure 7.5.3, below, shows the results for Ordered Face Trisection graphs of 42-4500 vertices. It 
shows the same properties as the previous graph types: 

• The best approximation to the data is a linear best-fit; and 

• Intermittent outliers are present in the results-set at constant time intervals. 

However, as per the Planar Wheel graph when the root vertex is the N th vertex, it also has 
a non-linear progression to the mean segment depth and, correspondingly, the mean segment 
depth provides the worst fit to the data. 

Table 7.5.6, below, shows a summary of the MAEs from that figure and from the results of the 
other root vertices. All these results-sets have the same properties; however, where the mean 
segment depth for the first vertex is a smooth, if bumpy, curve the other root vertices follow a 
similar curve but it is not smooth as there is much more noise (spikes in the best-fit line) above 
this curve. 



Root 


y — ax + b 


y — axln (x) 


y — axln (In (a;)) 


Mean Seg. 


Figure 






+b 


+b 


Depth 




1 


1776027 


1958275 


1833359 


5008230 


7.5.3 


1/4N 


3665093 


3854375 


3722815 


8571908 


A.2.26 


1/2N 


1225056 


1414951 


1285655 


5953908 


A.2.27 


3/4N 


1553096 


1725039 


1600865 


7000747 


A.2.28 


N 


1406122 


1598605 


1467602 


5889114 


A.2.29 



Table 7.5.6: Mean Absolute Error for Best-Fit Curves to Ordered Face Trisection (42-4500 
Vertices) Results 
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Table 7.5.7, below, shows the results for the same root vertices for Ordered Face Trisection 
graphs with 500-15000 vertices and indicates, again, that: the best approximation to the data 
is given by a linear fit; and that the mean segment depth fit is the worst approximation to the 
data (having approximately twice the MAE of a linear fit). 



Root 


y — ax + b 


y = axln (x) 


y — axln (In (a;)) 


Mean Seg. 


Figure 






+b 


+b 


Depth 




1 


6278093 


6659470 


6351021 


14929242 


A.2.30 


1/4N 


11120304 


11551287 


11233880 


23502400 


A.2.31 


1/2N 


12676386 


13071826 


12785937 


28158443 


A.2.32 


3/4N 


12166627 


12545700 


12280494 


23864311 


A.2.33 


N 


10363658 


10799158 


10480651 


24069355 


A.2.34 



Table 7.5.7: Mean Absolute Error for Best-Fit Curves to Ordered Face Trisection (500-15000 
Vertices) Results 



Figure 7.5.4, below, shows the results for 42-4500 vertex Random Face Trisection graphs where 
the root vertex is the 1 st (central) vertex. Again, showing: that the best approximation to the 
data is a linear fit; that the mean segment depth is the worst approximation to the data with an 
MAE of approximately twice that for the other fits; and there are intermittent outlying results 
which regular time intervals. The result-set also shows a similar pattern in the mean segment 
depth as for Planar Wheel and Ordered Face Trisection graphs of the same, 1 st , root vertex; in 
these cases the mean segment depth is non-linear and asymptotic. 

x -jo 7 Random Face Trisection Graph (Root = 1st) 

10 r 




y=7474221.161f(x)-64847467.2468 
(Robust Regression, MAE = 6443628) 



500 1000 1500 2000 2500 3000 3500 4000 4500 

Number of Vertices 



Figure 7.5.4: Random Face Trisection Graph (42-4500 Vertices, 1 st Vertex Root) 
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Table 7.5.8 summarises the MAE for that results-set and for the results from other root vertices 
for Random Face Trisection graphs of 42-4500 vertices. In all cases: 

• The linear best-fit has a negative y-intercept and the data diverges from the linear best-fit 
when the graph sizes are small. 

• The mean segment depth best-fit has the highest MAE, indicating that it is the worst 
approximation to the data. Also, all the mean segment depths appear asymptotic as the 
graph size increases; however when the root vertex is not the 1 st vertex the mean segment 
depth follows a similar curve to the smooth curve for that 1 st vertex root although there 
is a lot of noise around this curve. 

• There are inermittent outliers in the results which appear at approximately regular time 
intervals. 

In most cases, the linear best-fit has the lowest MAE, indicating that it is the best approximation 
to the data. In the case where the root vertex is the 3 /4./V th vertex the log-log best-fit is the best 
approximation; however, repeating the analysis with same data but excluding graphs containing 
less than 400 vertices then linear best-fit gives the best approximation - indicating that the 
small graph sizes skewed the analysis in this case. 



Root 


Minimum 


y — ax + b 


y — axln (x) 


y — axln (In (x)) 


Mean Seg. Figure 




Graph Size 




+b 


+b 


Depth 




1 


42 


3637976 


3781079 


3680166 


6443628 


7.5.4 


1/4N 


42 


2116531 


2293644 


2172621 


6335956 


A.2.35 


1/2N 


42 




2588612 


2467059 


7212265 


A.2.36 


3/4N 


42 


2632114 


2679508 


2618944 


7039375 


A.2.37 


3/4N 


400 




2854157 


2782140 




A.2.39 


N 


42 


1816324 


1953147 


1853941 


6737186 


A.2.38 



Table 7.5.8: Mean Absolute Error for Best-Fit Curves to Random Face Trisection (up to 4500 
Vertices) Results 



Table 7.5.9 shows similar results for the same (proportionally) root vertices for Random Face 
Trisection graphs of up to 15000 vertices. These results show the same properties as above. 



Root 


Minimum 


y — ax + b 


y = axln (x) 


y — axln (In (x)) 


Mean Seg. Figure 




Graph Size 




+b 


+b 


Depth 




1 


500 


8992789 


9277734 


9021704 


17181059 


A.2.40 


1/4N 


500 


7586314 


7909207 


7629515 


20201626 


A.2.41 


1/2N 


500 


10022019 


10332961 


10064013 


25609920 


A.2.42 


3/4N 


500 


9945233 


10076222 




27912475 


A.2.43 


3/4N 


750 


10056748 


10270388 


10075262 




A.2.45 


N 


500 


8474118 


8778526 


8523768 


22573254 


A.2.44 



Table 7.5.9: Mean Absolute Error for Best-Fit Curves to Random Face Trisection (up to 
15000 Vertices) Results 
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7.5.1 Conclusions for Empirical Testing on Maximal-Planar Graphs 
of Varying Size 

Several conclusions can be drawn from the results in this section: 

1. The best approximation is a linear best-fit between the algorithm's execution time and 
the graph size for a fixed (maximal planar) graph type and a fixed (as a proportion of the 
size of the graph) root vertex; 

2. The mean segment depth does not give a good approximation to the algorithm's execution 
time, unless it is also (approximately) linear; 

3. The linear best-fit has a negative y-intercept (as is the case for Hopcroft and Tarjan's 
algorithm [32, Pg. 565]); 

4. Expanding the previous point - for graphs with small (< 750) numbers of vertices, the 
empirical testing results diverged from the, corresponding, linear-best fits (which, given 
the negative y-intercept, predicts near zero or negative execution times) and these small 
graphs could distort the best-fit analysis emphasising a non-linear fit where that fit was 
less appropriate when considering the graphs larger than that limit; and 

5. The results were regularly and repeatedly interrupted by an intermittent external event 
which adds a constant scale factor to those results generated in within its time frame. 
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7.6 Empirical Testing on Graphs of Constant Vertex- Size 
and Varying Edge- Size 

This section extends the previous to look at biconnected graphs, rather than just maximal planar 
graphs, and considered the case when multiple embeddings of a graph are possible. 

Table 7.6.1, below, summarises the empirical testing results for biconnected sub-graphs (with 
between approximately 30,000 and 45,000 edges) generated by deleting cotree edges (which are 
each the sole edge of a segment) of 14999 vertex Triangular Prism, Planar Wheel, Ordered Face 
Trisection and Random Face Trisection graphs and for different root vertices. The table contains 
the MAEs for the best-fits y = ax + b, y = axln (x) + b and y = axln (In (x)) + b for each of these 
graph types and the lower the MAE the better the approximation that fit is towards the data. 



Graph 
Type 


Root 


y — ax + b 


y = axln (x) y 
+b 


= axln (In (x)) 
+b 


Figure 




1 




15541986 


15542722 


15542137 


A.3.1 




1/4N 


14788546 


14765916 


14779177 


A.3.2 




!/4N (2) 


19076118 


19055515 


19067521 


A.3.3 


TP 


1/2N 


14014165 


14023381 


14017703 


A.3.4 




3/4N 


13953239 


13957438 


13954722 


A.3.5 




N 


14156578 


14160763 


14158026 


A.3.6 




1 


16400791 


16405925 


16402689 


A.3.7 




1/4N 


17279038 


17281242 


17279758 


A.3.8 


PW 


1/2N 


13161375 


13174988 


13166686 


A.3.9 


3/4N 


12951990 


12965026 


12957054 


A.3.10 




N 


16315376 


16316008 


16315450 


A.3.11 




1 


20678436 


20679501 


20678696 


A.3.12 




1/4N 


22395179 




22394051 


A.3.13 




1/4N (2) 


16173935 


16181328 


16176750 


A.3.14 


OFT 


1/2N 


18556445 


18557985 


18556870 


A.3.15 




3/4N 


16568619 


16574276 


16570723 


A.3.16 




N 


20754869 


20756816 


20755480 


A.3.17 




1 


16861982 


16867804 


16864137 


A.3.18 




1/4N 


16791247 


16794352 


16792280 


A.3.19 


RFT 


1/2N 


14939222 


14948367 


14942765 


A.3.20 


3/4N 


15082308 


15083301 


15082542 


A.3.21 




N 


15997322 


16002293 


15999185 


A.3.22 



Table 7.6.1: Mean Absolute Error for Best-Fit Curves to Biconnected Triangular Prism (TP), 
Planar Wheel (PW), Ordered Face Trisection (OFT) and Random Face Trisection (RFT) 
Sub-Graph Results (14999 Vertices, -30000-45000 Edges, Various Root Vertices) 



The MAEs show that in most cases a linear fit provides the best approximation to the data. 
However there are two cases where this is not the case that are discussed below. 
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Execution Time of 
14999 Vertex Ordered Face Trisection Graph (Root = %Nth) 



_ y=2757.1 843X-931 7546.9981 
(Robust Regression, MAE = 21457902) 
y=239.752xln(x)-655888.0867 
(Robust Regression, MAE = 21459384) 

_ y=1 1 26.9485xln(ln(x))-5439476.3557 
(Robust Regression, MAE = 21458414) 



g 1.8 - 
E 



' 3 3.2 3.4 3.6 3.8 4 4.2 4.4 

Number of Edges x -| q 4 

Figure 7.6.1: Ordered Face Trisection Graph (14999 Vertices, -30000-43000 Edges, i/4iV th 
Vertex Root) 

The more trivial of the cases where a linear fit is not indicated by the MAEs is the Ordered 
Face Trisection sub-graphs when the root vertex is the 1 /iN th vertex. Examining figure A. 3. 13 
(page 216) shows a small increase in execution times at about 44,000±500 edges (and is more 
noticeable in the outliers) but this is enough to skew the MAEs towards a non-linear fit. 
Figure 7.6.1, above, shows the same data with the results for sub-graphs with 43,000-45,000 
vertices excluded and the MAEs are summarised in table 7.6.2, below. With these exclusions 
the results indicate a linear fit is the best approximation to the data. 

Performing a second run (figure A. 3. 14, page 216) of that benchmark (MAEs summarised in 
table 7.6.1, above) validates this as there is no similar increase in execution times within that 
edge range for that run and the MAEs indicate that, without any exclusions, a linear fit gives 
the best approximation to the data. This suggests that the increase in execution times in first 
benchmark was an anomaly. 

Root Edges y — ax + 6 y — axln (x) y — axln (In (a;)) Figure 

+b +b 

1/4N < 43000 21357341 21359338 21358064 7.6.1 

Table 7.6.2: Mean Absolute Error for Best-Fit Curves to Ordered Face Trisection Sub-Graph 
Results (14999 Vertices, Varying Edges) 

Of more interest are the two benchmarks performed for Triangular Prism sub-graphs where the 
root vertex is the 1 /4N th vertex. Examining figures A. 3. 2 & A. 3. 3 (page 209) shows that a step 
is apparent in the results at approximately 40,000 edges. 

Figures 7.6.2 & 7.6.3, below, show these results-sets split at 40,000 vertices and the MAEs 
are summarised in table 7.6.3; these results indicate that above and below this step the best 
approximation to the data is a linear fit. 
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Execution Time of 1 4999 Vertex 
Triangular Prism Graph (Root = %Nth) 



y=3243.01 22x-1 4500902.5968 
(Robust Regression, MAE = 13248700) 
y=283.0039xln(x)-4667432.4798 
(Robust Regression, MAE = 13250359) 
_ y=1 327.4342x-ln(ln(x))-1 0090777.91 88 
(Robust Regression, MAE = 13249331) 



Execution Time of 14999 Vertex 

Triangular Prism Graph 
x10 B (Root = %Nth) 



y=361 5.8504X-24982802.41 58 
(Robust Regression, MAE = 17246334) 
y=310.1811x-ln(x)-1 18081 17.8733 
(Robust Regression, MAE = 17246706) 
_ y=1 469.81 95xln(ln(x))-1 91 251 05.7497 
(Robust Regression, MAE = 17246491) 




4.1 4.2 4.3 4.4 4.5 



Number of Edges x -jq 4 Number of Edges x -jq 4 

Figure 7.6.2: Biconnected Sub-Graphs of Triangular Prism Graph (14999 Vertices, ~30000- 
45000 Edges (Split at 40000 Edges), i/47V th Vertex Root) 



Execution Time of 14999 Vertex 
Triangular Prism Graph (Root = %Nth, 2nd Run) 



_ y=3246.2639x-1 4072977.8666 
(Robust Regression, MAE = 17112392) 
y=283.277xln(x)-4226969.2836 
(Robust Regression, MAE = 17112689) 

_ y=1 328.741 6xln(ln(x))-9657064.4457 
(Robust Regression, MAE = 17112467) 



Execution Time of 14999 Vertex 

Triangular Prism Graph 
x K^Root = '/.Nth, 2nd Run) 

3r 



y=3287.6089x-10574009.5116 
(Robust Regression, MAE = 23244357) 
y=282.01 94xln(x)+1 40621 4.8527 
(Robust Regression, MAE = 23244431) 
y=1 336.3675X ln(ln(x))-5245921 .1 846 
(Robust Regression, MAE = 23244412) 



3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4 4 4.1 4.2 4.3 4.4 4.5 

Number of Edges x ^g 4 Number of Edges x ^q 4 

Figure 7.6.3: Biconnected Sub-Graphs of Triangular Prism Graph (14999 Vertices, ~30000- 
45000 Edges (Split at 40000 Edges), i/iN th Vertex Root) 



Root 


Edges 


y — ax + b 
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+b 


+b 




1/4N 


< 40000 


13248700 


13250359 


13249331 


7.6.2 


1/4N 


> 40000 


17246334 


17246706 


17246491 


7.6.2 


1/4N (2) 


< 40000 


17112392 


17112689 


17112467 


7.6.2 


1/4N (2) 


> 40000 


23244357 


23244431 


23244412 


7.6.2 



Table 7.6.3: Mean Absolute Error for Best-Fit Curves to Triangular Prism Sub-Graph Results 
(14999 Vertices, Varying Edges) 
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Figure 7.6.4 shows some of the changing properties relating to the structure of the Triangular 
Prism sub-graphs for that !/4iV th root vertex. It shows two very noticeable traits: 

1. The sub-graphs with less than 40,000 edges have no conflicts between segments whereas 
those with greater than 40,000 edges have an (approximately linearly) increasing number 
of conflicts between segments. 

2. The mean segment depth for those sub-graphs shows a maxima at approximately 34,500 
edges and a point of inflexion at 40,000 vertices; corresponding to this point of inflexion 
is a distinct change to the gradient of the mean segment depth curve and, even more 
distinct, the acceleration of the mean segment depth curve changes from a smooth curve 
to a pattern reminiscent of harmonic dampening. 



Segment Conflicts for Biconnected Sub-Graphs of 
14999 Vertex Triangular Prism 
Graph (Root = '/.Nth Vertex) 
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Mean Segment Depth for Biconnected Sub-Graphs of 
14999 Vertex Triangular Prism 
Graph (Root = '/.Nth Vertex) 

6000 r 




Number Of Edges 




Figure 7.6.4: Mean Segment Depth for Biconnected Sub-Graphs of Triangular Prism Graph 
(14999 Vertices, -30000-45000 Edges, i/47V th Vertex Root) 



Appendix A. 4 shows the changes to the numbers of conflicts and to the mean segment depth 
for the other graph types and root vertices. The only other instance of a similar change is also 
for the Triangular Prism sub-graphs when the root vertex is the 1 /2N th vertex (figure A. 4. 2, 
page 222) ; this results-set shows a change in the number of conflicts and a point of inflexion in 
the mean segment depth curve (and, corresponding, change in the gradient and acceleration of 
the mean segment depth from a smooth curve to a reducing sine wave) . Examining the empirical 
data for this results set (figure A. 3. 4, page 210) also shows a small step in the results but it is 
almost inconsequential 8 compared to the step for the 1 /4N th root vertex and the linear fit is still 
the best approximation to the data in this case. 

The other graph types and root vertices (figures contained in appendix A. 4) shows comparable 
changes in gradient to the two above but none of the other graphs show such a distinct change 
in the acceleration of the mean segment depth curve from a smooth curve to a sinusoidal curve 
of reducing amplitude. 

• The other Triangular Prism results-sets show either a smooth curve or a reducing amplitude 

8 And probably would not have been remarked upon if the mean segment depth had not been analysed 
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sinusoidal curve but they do not both occur together outside the 1 /4N th and 1 /2N th root 
vertex results-sets. 

• The Planar Wheel results-sets all show smooth curves for the mean segment depth with 
reducing gradient until an approximately constant gradient is reached. 

• The Ordered Face Trisection results-sets all have a single change in gradient at about 
40,000 edges for the number of conflicts and the mean segment depth is characterised by 
discrete steps in the gradient separated by ranges of near constant gradient. 

• The Random Face Trisection result-sets all show a smooth curve for the number of conflicts 
and for the mean segment depth; although the gradient and the acceleration of the mean 
segment depth curve for this graph type show a lot of "random" noise, it is over a small 
range (which for the acceleration is consistently around zero except for when the number 
of edges approaches 45,000 when the acceleration increases negatively). 

A much more detailed analysis of these effects is needed along with a method of mutating 
the graph structure to generate different biconnected graphs with similar properties if these 
relationships are to be explored further. However, the lack of steps in the results-sets of the 
other graph types seems to indicate that: 

• The steps in the results-sets are not related to changes in the gradient of the frequency of 
conflicts as most results-sets show a sharp variation in the gradient and no step is present; 
and 

• Changes in the curve/gradient /acceleration for the mean segment depth are insufficient to 
induce a step in the results-sets. 

However, a fundamental change in the pattern of acceleration for the mean segment depth curve 
(as can be seen for those two Triangular Prism sub-graph results-sets but is not in evidence 
for the others) may be the cause (or a related symptom) of the existence of that step in the 
execution times. 
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7.7 Empirical Testing on Permutable, Flippable Graphs of 
Varying Size 



Table 7.7.1, below, summarises the MAEs from the execution times of various root vertices for 
Permutable, Flippable graphs (see section 7.3.5, page 134) with 500-7500 facets (1002-15002 
vertices). 



Root 


y — ax + b 


y — axln (x) 


y — axln (In (a;)) 


Mean Seg. 


Figure 






+b 


+b 


Depth 




1 


8793283 


8890456 


8804118 


20124000 


A.5.1 


1/4N 


9588673 


9777305 


9642010 


19954875 


A.5.2 


1/2N 


10154894 


10320925 


10201495 


20405195 


A.5.3 


3/4N 


9775322 


9943227 


9822890 


20167180 


A.5.4 


N 


9766313 


9882703 


9796296 


19937485 


A.5.5 



Table 7.7.1: Mean Absolute Error for Best-Fit Curves to Permutable Flippable Graph Results 
(1002-15002 Vertices) 



The table shows that, in all cases, a linear fit gives the best approximation to the data and that 
the mean segment depth is the worst approximation to the data with approximately double the 
error of the other fits. 

The results for Permutable, Flippable graphs when the root vertex is the 1 /4N th , l /^N , 3 /4jV th 
and N th (figures A.5.2-A.5.5) all show a positive y-intercept; however, as with all previous 
results, when the root is the 1 st vertex the y-intercept is negative. 
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7.8 Conclusions 

Considering the variation in the root vertex: 

• Varying the root vertex for Triangular Prism and Planar Wheel graphs varies the execution 
time such that and the results-sets for the same graph type exhibited similar trends in the 
execution time as root vertex varied as a proportion of the graph size. 

• A similar property can be noted for Ordered Face Trisection and Random Face Trisection 
graphs; however this is to a lesser degree as the execution times are approximately constant 
as the root vertex varied. 

• In all cases, the mean segment depth best-fit gave a better or approximately equal 
approximation to the execution time than a constant value; this was particularly noticeable 
for the Triangular Prism and Planar Wheel graphs where the execution time and mean 
segment depth showed some significant variation as the root vertex changed (whereas the 
Ordered Face Trisection and Random Face Trisection graphs were relatively constant in 
both aspects). However, while the mean segment depth and the execution time share 
some characteristic, the mean segment depth does not always model the behaviour of the 
execution time and so other factors may need to be identified and considered to achieve a 
better model. 

Considering the variation in execution time for a corresponding variation in the graph size for 
maximal planar graphs of the same type and (proportional to the graph size) root vertex: 

• Typically, the analysis showed that the best approximation to the results-sets was given 
by a linear best-fit. 

• This linear best-fit took the form y = ax—b with a negative y-intercept; this is a comparable 
result to Hopcroft and Tarjan who noted that their planarity testing algorithm achieved an 
execution time of T = .01251^ — .07 [32, Pg. 565] (also exhibiting a negative y-intercept) . 

• Where the analysis did not indicate a best approximation by a linear best-fit then excluding 
results for small graphs of below 750 vertices indicated that, for the graphs larger than 
this size, a linear best-fit was the best approximation. This is a side-effect of finding a 
linear best-fit with a negative ^/-intercept (which means that the execution times for small 
graphs must diverge from the linear best-fit as negative execution times are impossible to 
achieve) and, since fitting curves tends to be more sensitive to anomalies and outliers at 
the extremes of the domain, this results in promoting a non-linear best-fit in these cases 
where it is not necessarily appropriate. 

• The results-set typically contained outlying data which appeared intermittently at 
approximately constant time intervals but these intervals were independent of the root 
vertex, graph type or size (as they varied with repeated benchmarks of the same graph 
and root vertex combinations); so the conclusion drawn is that these outliers are the 
impact of an external event interrupting (or sharing the processor with) the planarity 
testing algorithm's execution and are otherwise irrelevant. 

Considering the variation in execution time for a corresponding variation in the number of the 
graph's edges for biconnected sub-graphs of a fixed maximal planar graph and root vertex: 

• In all cases, the analysis showed that the best approximation to the results-set was given 
by a linear best-fit. 
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• Again, this linear best-fit took the form y = ax — b with a negative y-intercept. 

• Where the change in gradient of the mean segment depth displayed a distinct variation 
from a smooth curve to a sinusoidal curve of reducing amplitude (as per the Triangular 
Prism graphs for the 1 /iN th and !/2iV th root vertices) there was a step in the execution 
times at a corresponding number of edges and that the best approximation to the results- 
set above and below the step was a linear best-fit. 

Similarly, the results for Permutable, Flippable graphs showed that a linear fit gave the best 
approximation to the data; however, contrary to the previous results, the y-intercept for this fit 
against the majority of the results-sets was positive. 

Drawing this all together then the overall conclusion is that: 

CONCLUSION 7.8.1. The empirical testing shows that, for graphs with more than 750 
vertices, the best approximation to the data is a linear best-fit. 



More specifically, since each phase of the algorithm is theorised to execute in linear time and 
when tested empirically the sum of the execution times for all phases (including generating a 
cyclic edge order) was found to be linear then this implies that each individual phase of the 
algorithm is linear (since if any phase was non-linear then the total execution time would likely 
have been non-linear). 

Further Analysis 

Further analysis can be performed to consider whether it is possible to generate a model that 
can approximate the behaviour of the algorithm: 

1 . The results have shown that changes in mean segment depth as the number of vertices or 
edges increases does not give a good approximation to the change in execution time; 
however, the mean segment depth did approximate (to some degree) changes in the 
execution time as the root vertex varied and the graph was otherwise fixed. Given this 
then one avenue of investigation would be whether the mean segment depth gives any 
approximation to the gradient of the linear fit against execution time as the number of 
vertices and edges increases. 

2. Other factors (such as numbers of conflicts, blocks, children, etc.) can also be considered to 
see whether they can be used to model the behaviour of the algorithm. Cursory analysis of 
the data rejected those models listed above and several others relating to the combination 
of segment depth multiplied by numbers of children or of conflicts; however, a more detailed 
analysis would be useful to validate this viewpoint. 

3. For most graph type, size and root vertex combinations the linear best-fit's y-intercept 
is negative; however, for Flippable, Permutable graphs where large proportions of the 
segments being either part of a 'permutable group or of flippable blocks then the y- 
intercept was, for the most part, positive. Repeating these benchmarks and generating 
new benchmarks with graphs of similar properties would validate whether the number of 
permutable or flippable segments has any correlation to the y-intercept or if these results 
were coincidence. 

One particular area where more analysis could be focused is on biconnected sub-graphs of 
triangular prism graphs - in particular, what causes the step to appear in the execution times 
and whether it is linked to any particular structure in the graph or the segment hierarchy. 



Chapter 8 



Conclusions 



This chapter draw together the conclusions from the previous chapters: 

Chapter 2 gives an overview of the field of planarity testing and the various approaches that have 
been taken to the problem. All the published algorithms which consider planarity testing and 
generate an embedding form a single embedding of that graph and it is not possible to manipulate 
them to generate alternate embeddings. Although, Haeupler and Tarjan published an extended 
abstract giving a brief summary of a method for generating all possible embeddings using PQ- 
trees, there is no detail to the algorithm making it difficult (impossible?) to implement. As such, 
the conclusion was drawn that there were no published algorithms to generate all embeddings 
of a biconnected graph in a time bound linear to the size of the graph (for each embedding) . 

Chapters 3-4 gives the theory behind the algorithm detailing how and why it works. The 
explanation of the algorithm is deeply linked to the properties of Tremaux Trees and the 
subsequent generation and ordering of Segments induced from this tree structure. The resulting 
planarity test stems from the invariant properties associated with these structures and orderings 
and these two chapters detail these invariant properties and the relationships needed to test for 
planarity and, if successful, perform an embedding. 

Given these invariant properties and the relationships defined by the hierarchy and ordering 
of segments then the algorithm (chapter 5) is relatively simple as correct generation of: the 
Tremaux Tree; the segments; and their ordering induces all the invariant properties and then 
it becomes a matter of checking whether each segment and block is either fully embedded or 
whether they can be flipped so as to permit an embedding. 

In the consideration of the theory, no restriction was placed on the nature of the graph beyond 
the fact that it should be connected. Chapters 3-4 consider the case of separable and biconnected 
graphs equally and show that no differentiation needs be made between the two for the purposes 
of planarity testing as the algorithm can test both equally well. Thus the conclusion is drawn 
that Hopcroft and Tarjan's restriction on biconnected graphs can be relaxed and any connected 
graph can be tested via a path addition method. 

Chapter 5 also contains an algorithm to allow permutation of a biconnected graph via either 
Whitney Flips or permutation of edges with an equivalent precedence ordering so as to achieve 
all possible embeddings of a biconnected graph in linear time complexity. Chapter 4 also 
details techniques to generating all embeddings of Class 1 and 2 segments about each common 
head vertex in a linear time complexity. Similarly, included are details of how to generate 
all embeddings of Class 3 segments about each common head vertex, including accounting for 
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descendants of those segments which may also terminate at that common vertex; however, 
no method has yet been identified to implement the creation and manipulation of the data 
structures involved to perform this operation in linear time and memory and this remains as an 
open question from this work. 

Chapter 5 details the algorithm relating it back to the earlier chapters and to the similarities 
and differences with Hopcroft and Tarjan's work; there are several differences: 

• The main difference is that Hopcroft and Tarjan's algorithm ensures that each path is 
embedded onto the left (inside) stack which results in additional flips within the data 
structure that may be unnecessary; this then may result in segments being moved that 
can only be embedded within the inside region (relative to its parent) to the right stack 
breaking the affordance between the stacks and the regions and making it much harder to 
generate an embedding. The algorithm presented here maintains the affordance between 
the stacks and the regions by relaxing the embedding process and allowing segments to be 
embedded in both the inside and outside regions (as appropriate); this keeps the natural 
affordance between stacks and regions and simplifies the embedding process. 

• Another change is that the data structures are maintained as the embedding is generated. 
By having a list for partially embedded and a list of all embedded segments within a 
block then, as per H&T, the partially embedded segments can be appended and discarded 
from the data structure while their presence is maintained in the list of all segments thus 
preserving the embedding information for use when generating a cyclic edge order. This 
change can be made independently of the other variations between algorithms and could 
equally be applied to H&T's original algorithm. 

• The final difference (and main emphasis of this work) is in the identification of multiple 
embeddings. By identifying that the transformations of the data structure in H&T's 
algorithm are performing Whitney flips within the embedding and identifying cases where 
these are restricted from occurring then this has lead to an algorithm that can identify all 
possible embeddings of a biconnected graph (and all components of connected graphs so 
future work can be performed on an efficient means on combining these components). 

Chapter 5 also investigates the upper time bound for the algorithm concluding that for a graph 
S (V, £) with segments § then: 

• Tremaux Tree and segment generation have an 0(V + £) upper time bound; and 

• Planarity testing and permuting the data structure for the embedding have an 0(S) upper 
time bound (where 0(§) < 0(£)). 

• The generation of a cyclic edge order has 0(§ + £) upper time bound. 

For all connected graphs, both the number of vertices and the number of segments is less than 
one plus the number of edges. Therefore, these upper time bounds can be simplified to all being 
0(£) and the conclusion drawn is that the theoretical time bound for execution of this algorithm 
is linear. 

Chapter 7 contains empirical testing of the algorithm to test this theorised time bound. The 
empirical testing shows that in all cases a linear best-fit provides the best approximation to 
the results when the graph has more than 750 vertices. This linear best-fit has, in both the 
empirical results for this algorithm and in Hopcroft and Tarjan's paper [32], a negative value 
for the y-intercept - no conclusion is drawn to the reason for this occurrence but a negative 



CHAPTER 8. CONCLUSIONS 



169 



execution time is clearly impossible and so it is not surprising that the empirical tests for small 
graph sizes do not fit to a linear best-fit. 

The overall conclusion from these results indicate that the theoretical linear time bound for the 
algorithm is not invalidated by the empirical testing; so the algorithm is accepted to have a 
linear time bound. 



8.1 Future Work 

Several areas of interest have been identified during this work that can benefit from further 
work: 

The one area where a linear time bounded implementation has not been identified is the 
generation of all possible embeddings of multiple Class 3 segments about a common head vertex. 
A sketch of a technique to achieve this result has been included on page 66 but an efficient data 
structure has not been identified to manage the reorganisation of the segments, especially when 
those Class 3 segments have descendants that also terminate at that common head vertex. 

The algorithm presented is intended as a demonstration of the principles of performing this test 
and embedding; it has not been optimised and various strategies can be considered: 

• It should be possible to generate the segments during backtracking of the initial DFS 
search and then bucket sort the segments to order each segment's children rather than 
bucket sorting the edges and subsequently generating the segments; this should improve 
the efficiency of the first two phases of the algorithm. 

• One avenue of investigation is to consider whether a cyclic edge order can be generated 
during the embedding of the segments. This could be considered by trying to integrate 
a PQ-Tree data structure into the embedding such that Q-nodes are used to represent 
the embedding of flippable segments/blocks and P-nodes are used to represent groups of 
permutable segments. A thorough investigation needs to be performed on the relationship 
between the embedding of segments and the transformations of the cyclic edge orders to 
determine if this data structure is actually appropriate as it is not immediately clear if 
this is the case. 

In considering the utility of this algorithm, these could include: those that are interested in 
testing for the existence of specific faces within an embedding (chemical compositions); testing 
an embedding against metrics to find an optimal embedding (circuit board design or graphical 
design of layouts); or to find a specific embedding (graph isomorphism). In all these cases, 
the segment and block hierarchy is constant once a graph is embedded and by divorcing the 
generation of an embedding and the associated blocks from the generation of a cyclic edge order 
allows for the interesting possibility of considering the parallelisation of the process of generating 
and testing large numbers of embeddings against specific metrics. One can also consider whether 
it is possible to improve on a brute force search when looking to test embeddings of a graph 
against specific metrics by considering whether performing specific flips and permutations can 
achieve a gradual improvement against a metric or if restricting certain flips or permutations 
can retain desired features in an embedding. 

The final area for future work is that the empirical testing has show that variations in the root 
vertex and in the graph structure give differing characteristics to the best-fits. Of particular 
interest is the results shown in figure A. 3. 2 (page 209) which shows a step in the graph and 
there is a corresponding change in the properties of the graph shown in figure 7.6.4 (page 162). 
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A more detailed analysis of different graph structures could be performed to identify structures 
which require more or less time to test and embed and what structures cause the step change 
in execution time. 



Appendix A 



Empirical Testing Figures 



This appendix chapter contains plots of various result generated during empirical testing. Each 
plot presents best-fits for curves of different shapes against the timing data from the empirical 
testing for specific input conditions (number of vertices and edges of the graph and choice of 
root vertex and graph structure); whilst the best-fit curves are displayed graphically, the curves 
are often overlapping (or close to it) making distinguishing the features of the curve difficult 
and so the pertinent information is displayed numberically in the legend of each plot. 

The results can be partitioned into three groups: 

• Variation in the choice of root vertex whilst keeping the graph size and structure constant; 

• Variation in the graph size (number of vertices, and proportionally, the number of edges 
and segments) whilst keeping the graph structure and, proportinal to the size, the choice 
of root vertex constant; and 

• Variation in the number of edges of the graph whilst keeping the number of vertices, graph 
structure and root vertex constant. 

The following plots fit into one of the above categories and are included in the appendix because 
it is difficult to elicit a quantitive comparison of the best-fit curve in the same plot using the 
graphical representation and so the important information on the best-fit curves is the numerical 
data contained in the legend which can be summarised in the main body of this work without 
overburdening it by adding multiple pages of plots. The plots do, however, show some additional 
features and anomalies and, where pertinent, a single example is drawn into the main body of 
work to highlight these whilst additional examples remain here. 

The matlab code used to generate the plots contained here, and in the main body of work, is 
included in Appendix E. 
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A.l Variations in Root Vertex for Constant Graph Size and 
Type 

A. 1.1 Triangular Prism Graphs 



250 Vertex Triangular Prism Graph (98th Percentile) 

• 75-98 1 " %ile Data 
1 50-75 1 " %ile Data 

• 25-50 1 " Voile Data 

• 0-25 lh %ile Data 
y=+1523704.8439 

(Robust Regression, MAE = 19615) 

y=638.254f(x)+1480352.3296 

(Robust Regression, MAE = 16692) 
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Figure A. 1.1: Execution Times for Varying Root Vertices of 250 Vertex Triangular Prism 
Graph 
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500 Vertex Triangular Prism Graph (98th Percentile) 



75-98 1 " %ile Data 

50-75 1 " %ile Data 

25-50 1 " %ile Data 

0-25 lh %ile Data 
_y=+3867677.336 

(Robust Regression, MAE = 71988) 
_ y=1 591 .51 68f(x)+365571 7.7475 

(Robust Regression, MAE = 54032) 
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Figure A. 1.2: Execution Times for Varying Root Vertices of 500 Vertex Triangular Prism 
Graph 



750 Vertex Triangular Prism Graph (98th Percentile) 
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75-98 1 " %ile Data 
50-75 lh %ile Data 
25-50 1 " %ile Data 
0-25 1 " %ile Data 
y=+6245842.4556 

(Robust Regression, MAE = 118765) 
y=1 558.9371 f(x)+5934267.2558 
(Robust Regression, MAE = 100171) 
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Figure A. 1.3: Execution Times for Varying Root Vertices of 750 Vertex Triangular Prism 
Graph 
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1250 Vertex Triangular Prism Graph (98th Percentile) 

• 75-98 1 " %ile Data 
50-75 1 " %ile Data 
25-50 1 " %ile [ 
0-25 lh %ile Data 
y=+1 0899949.3981 
(Robust Regression, MAE = 196180) 
y=1 200.3341f(x)+1 0497464.01 1 8 
(Robust Regression, MAE = 180767) 
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Figure A. 1.4: Execution Times for Varying Root Vertices of 1250 Vertex Triangular Prism 
Graph 



1500 Vertex Triangular Prism Graph (98th Percentile) 
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Figure A. 1.5: Execution Times for Varying Root Vertices of 1500 Vertex Triangular Prism 
Graph 
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250 Vertex Planar Wheel Graph (98th Percentile) 
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Root Vertex ID 



• 75-98'" %ile Data 

• 50-75 1 " %ile Data 

• 25-50 1 " %ile Data 

• 0-25 lh %ile Data 
y=+1 264580.2234 

(Robust Regression, MAE = 35167) 

y=7068.6281f(x)+1 161576.1099 

(Robust Regression, MAE = 16282) 



Figure A. 1.6: Execution Times for Varying Root Vertices of 250 Vertex Planar Wheel Graph 



500 Vertex Planar Wheel Graph (98th Percentile) 
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75-98 1 " %ile Data 

50-75 1 " %ile Data 

25-50 1 " %ile Data 

0-25 lh %ile Data 

y=+3167609.7831 

(Robust Regression, MAE = 89653) 

y=10843.8995f(x)+2861 362.5451 

(Robust Regression, MAE = 38959) 
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Figure A. 1.7: Execution Times for Varying Root Vertices of 500 Vertex Planar Wheel Graph 
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750 Vertex Planar Wheel Graph (98th Percentile) 




75-98 ,h Voile Data 
50-75 lh %ile Data 
25-50 ,h %ile Data 
0-25 lh %ile Data 
y=+5159454.2227 
(Robust Regression, MAE = 97213) 
_ y=6740.01 04f(x)+49081 24.1 678 
(Robust Regression, MAE = 51 124) 



Figure A. 1.8: Execution Times for Varying Root Vertices of 750 Vertex Planar Wheel Graph 




Figure A. 1.9: Execution Times for Varying Root Vertices of 1250 Vertex Planar Wheel Graph 
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1 500 Vertex Planar Wheel Graph (98th Percentile) 
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Figure A. 1.10: Execution Times for Varying Root Vertices of 1500 Vertex Planar Wheel 
Graph 
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A. 1.3 Ordered Face Trisection Graphs 

x -IQ 6 250 Vertex Ordered Face Trisection Graph (98th Percentile) 
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Figure A.l.ll: Execution Times for Varying Root Vertices of 250 Vertex Ordered Face 
Trisection Graph 
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500 Vertex Ordered Face Trisection Graph (98th Percentile) 
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(Robust Regression, MAE = 78646) 
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Figure A. 1.12: Execution Times for Varying Root Vertices of 500 Vertex Ordered Face 
Trisection Graph 



750 Vertex Ordered Face Trisection Graph (98th Percentile) 
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Figure A. 1.13: Execution Times for Varying Root Vertices of 750 Vertex Ordered Face 
Trisection Graph 
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1250 Vertex Ordered Face Trisection Graph (98th Percentile) 
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(Robust Regression, MAE = 46152) 
_ y-5488.983f(x)+9281 039.2757 
(Robust Regression, MAE = 46049) 
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Figure A. 1.14: Execution Times for Varying Root Vertices of 1250 Vertex Ordered Face 
Trisection Graph 



1500 Vertex Ordered Face Trisection Graph (98th Percentile) 
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y=5420.2083f(x)+1 1 329447.381 8 

(Robust Regression, MAE = 140420) 



Root Vertex ID 



Figure A. 1.15: Execution Times for Varying Root Vertices of 1500 Vertex Ordered Face 
Trisection Graph 
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2000 Vertex Ordered Face Trisection Graph (98th Percentile) 
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Figure A. 1.16: Execution Times for Varying Root Vertices of 2000 Vertex Ordered Face 
Trisection Graph 
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A. 1.4 Random Face Trisection Graphs 

x -|o 6 250 Vertex Random Face Trisection Graph (98th Percentile) 
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Figure A. 1.17: Execution Times for Varying Root Vertices of 250 Vertex Random Face 
Trisection Graph 
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500 Vertex Random Face Trisection Graph (98th Percentile) 
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Figure A. 1.18: Execution Times for Varying Root Vertices of 500 Vertex Random Face 
Trisection Graph 



750 Vertex Random Face Trisection Graph (98th Percentile) 
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Figure A. 1.19: Execution Times for Varying Root Vertices of 750 Vertex Random Face 
Trisection Graph 
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1250 Vertex Random Face Trisection Graph (98th Percentile) 
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(Robust Regression, MAE = 773620) 
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(Robust Regression, MAE = 773615) 



600 800 
Root Vertex ID 



Figure A. 1.20: Execution Times for Varying Root Vertices of 1250 Vertex Random Face 
Trisection Graph 
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Figure A. 1.21: Execution Times for Varying Root Vertices of 1500 Vertex Random Face 
Trisection Graph 
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A. 2 Variation in Graph Size for Constant Graph Type and 
Root Vertex 

A. 2.1 Triangular Prism Graphs (42-4500 Vertices) 



Triangular Prism Graph (Root = %Nth) 




y=4436.8306xln(ln(x))+226621.8286 
(Robust Regression, MAE = 321899) 
y=31 71 0.3304f(x)-765991 .593 
(Robust Regression, MAE = 266797) 
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Figure A.2.1: Triangular Prism Graph (42-4500 Vertices, 1 /4N th Vertex Root) 



APPENDIX A. EMPIRICAL TESTING FIGURES 



x -IQ 7 Triangular Prism Graph (Root = 1 / 2 Nth) 

10 r 




(Robust Regression, MAE = 2710051) 
y =46076.981 8f(x)-81 6706.81 29 



(Robust Regression, MAE = 2667039) 



"0 500 1000 1500 2000 2500 3000 3500 4000 4500 

Number of Vertices 



Figure A.2.2: Triangular Prism Graph (42-4500 Vertices, 1 /2N th Vertex Root) 
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Figure A. 2. 3: Triangular Prism Graph (42-4500 Vertices, s/ 4 N th Vertex Root) 
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Triangular Prism Graph (Root = Nth) 
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y=27282.9723f(x)-755654.6856 
(Robust Regression, MAE = 438763) 



3500 



4000 



4500 



Figure A. 2.4: Triangular Prism Graph (42-4500 Vertices, N th Vertex Root) 



A. 2. 2 Triangular Prism Graphs (500-15000 Vertices) 



Triangular Prism Graph (Root = 1st) 

y=91 1 9.4628X-596020.9403 

(Robust Regression, MAE = 5953757) 
y=935.9629xln(x)+4245292.6417 
(Robust Regression, MAE = 6407003) 
y=4003.1 343xln(ln(x))+1 692036.7698 
(Robust Regression, MAE = 6074526) 

y=1 8238.9243f(x)-58841 4.4661 

(Robust Regression, MAE = 5953757) 
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Figure A. 2. 5: Triangular Prism Graph (500-15000 Vertices, 1 st Vertex Root) 
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Triangular Prism Graph (Root = %Nth) 



y=9508.7465x-399785.6878 
(Robust Regression, MAE = 10828822) 
y=974.0323x-ln(x)+4700185.5719 
(Robust Regression, MAE = 11378716) 
y=4170.4006xln(ln(x))+2029545.6307 
(Robust Regression, MAE = 11004559) 
y=31 477.2563f(x)-388888.1 1 77 
(Robust Regression, MAE = 10828827) 
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Figure A.2.6: Triangular Prism Graph (500-15000 Vertices, yiN th Vertex Root) 



Triangular Prism Graph (Root = V^Nth) 
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y=9602.8529x-89851 0.6949 
(Robust Regression, MAE = 11151 957) 
y=976.5834x-ln(x)+4826815.5704 
(Robust Regression, MAE = 11380733) 
y=4203.3263xln(ln(x))+1 692036.3418 
(Robust Regression, MAE = 11176692) 
y=46093.6966f(x)-903321 .7308 
(Robust Regression, MAE = 11151 956) 




Number of Vertices 



Figure A.2.7: Triangular Prism Graph (500-15000 Vertices, i/2iV th Vertex Root) 
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Triangular Prism Graph (Root = %Nth) 



y=9380.439x-852967.449 
" (Robust Regression, MAE = 1 1 271 872) 
y=963.9385x-ln(x)+4027476.0424 
(Robust Regression, MAE = 11670634) 
y=4127.9046xln(ln(x))+1 383002.0788 
(Robust Regression, MAE = 11346354) 
y=42882.01 76f(x)-925582.5803 
(Robust Regression, MAE = 11271872) 
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Figure A.2.8: Triangular Prism Graph (500-15000 Vertices, 3/ 4 jV th Vertex Root) 



Triangular Prism Graph (Root = Nth) 



y=9221 .7665X-820220.4298 
(Robust Regression, MAE = 7837889) 
y=944.41 52xln(x)+41 89828.9904 
(Robust Regression, MAE = 8233416) 
y=4053.061 6xln(ln(x))+1 454847.41 4 
(Robust Regression, MAE = 7922696) 
y=27665.2956f(x)-824819.2038 
(Robust Regression, MAE = 7837889) 
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Figure A.2.9: Triangular Prism Graph (500-15000 Vertices, N th Vertex Root) 
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A. 2. 3 Planar Wheel Graphs (42-4500 Vertices) 



Planar Wheel Graph (Root = '/.Nth) 

y=8833.9366x-1 277835.367 

(Robust Regression, MAE = 906099) 
y=1 032.8543x*(x)+27931 1 .8849 
(Robust Regression, MAE = 931009) 
y=41 05.6876xln(ln(x))-442381 .3479 
(Robust Regression, MAE = 859604) 

y=1 5901 0.2648f(x)-1 931 330.3355 

(Robust Regression, MAE = 906223) 
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Figure A.2.10: Planar Wheel Graph (42-4500 Vertices, i/4iV th Vertex Root) 



x -i o 7 Planar Wheel Graph (Root = '/ 2 Nth) 

10p 

y=9037.359x-1 1 75258.6751 

(Robust Regression, MAE = 3712651) 




500 1000 1500 2000 2500 3000 3500 4000 

Number of Vertices 



Figure A.2.11: Planar Wheel Graph (42-4500 Vertices, i/2iV th Vertex Root) 
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Figure A.2.12: Planar Wheel Graph (42-4500 Vertices, 3/ 4 jV th Vertex Root) 




Figure A.2.13: Planar Wheel Graph (42-4500 Vertices, 3/ 4 iV th Vertex Root, 2 nd Run) 
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x -| 7 Planar Wheel Graph (Root = Nth) 

10 p 

y=861 0.5625X-1 302401 .0363 

(Robust Regression, MAE = 301621) 
9 " y=1004.9424xln(x)+248487.8785 

(Robust Regression, MAE = 330432) 
y=3996.5957xln(ln(x))-4671 06.01 85 
8 "* (Robust Regression, MAE = 254431 ) 

y=347646971 6.8897f(x)-9825350395.661 2 

(Robust Regression, MAE = 8520598) 
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Figure A.2.14: Planar Wheel Graph (42-4500 Vertices, A th Vertex Root) 



Planar Wheel Graph (Root = 1st, Vertices > 750) 
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Figure A.2.15: Planar Wheel Graph (750-4500 Vertices, 1 st Vertex Root) 
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ID 

a 



Planar Wheel Graph (Root = YMtb, Vertices > 750) 



3 - 




_ y=8934.391 4x-1 558544.2397 
(Robust Regression, MAE = 1000452) 
y=1 01 8.7679xln(x)+621 956.1 01 3 
(Robust Regression, MAE ■ 1034677) 

_ y=41 05.855xln(ln(x))-440384.9458 
(Robust Regression, MAE = 1001089) 
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Figure A.2.16: Planar Wheel Graph (750-4500 Vertices, i/47V th Vertex Root) 




Figure A.2.17: Planar Wheel Graph (500-4500 Vertices, i/2Ar th Vertex Root) 
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Figure A.2.18: Planar Wheel Graph (750-4500 Vertices, 3/ 4 7V th Vertex Root) 




Figure A.2.19: Planar Wheel Graph (750-4500 Vertices, 3/ 4 7V th Vertex Root, 2 nd Run) 
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Planar Wheel Graph (Root = Nth, Vertices > 750) 




y=8699.7969x-1557289.6892 
(Robust Regression, MAE = 274585) 
y=991 .4083xln(x)+576272.5623 
(Robust Regression, MAE = 315838) 
y=3997.2654xln(ln(x))-466690.8702 
(Robust Regression, MAE = 277078) 
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Figure A.2.20: Planar Wheel Graph (750-4500 Vertices, N th Vertex Root) 



A. 2.4 Planar Wheel Graphs (500-15000 Vertices) 



Planar Wheel Graph (Root = 1st) 



y=8834.9936x-1 277204.3541 
(Robust Regression, MAE = 1238930) 
y=900.9361xln(x)+3626241 .651 1 
(Robust Regression, MAE = 1723401) 
y=3872.2908xln(ln(x))+98351 0.0447 
(Robust Regression, MAE = 1385571) 
y=1 59029.4608f(x)-1 81 1 460.3879 
(Robust Regression, MAE = 1238934) 
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Figure A.2.21: Planar Wheel Graph (500-15000 Vertices, 1 st Vertex Root) 
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Planar Wheel Graph (Root = '/.Nth) 

y=91 78.4296X-1 530284.0765 

(Robust Regression, MAE = 14849883) 
y=938.8941x-ln(x)+333371 9. 1 843 
(Robust Regression, MAE = 15158460) 
y=4023.5722xln(ln(x))+767490.9361 
(Robust Regression, MAE = 14890372) 

y=1 6521 1 .2596f(x)-22091 52.2301 

(Robust Regression, MAE = 14849903) 
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Figure A.2.22: Planar Wheel Graph (500-15000 Vertices, y<iN th Vertex Root) 



Planar Wheel Graph (Root = KNth) 



y=9045.824x-1 1 42389.3783 
(Robust Regression, MAE = 14165175) 
y=921 .3861x-ln(x)+3866753.5779 
(Robust Regression, MAE = 14614205) 
y=3959.772x-ln(ln(x))+1213217.4735 
(Robust Regression, MAE = 14302030) 
y=1 62824.61 56f(x)-1 499567.61 33 
(Robust Regression, MAE = 14165170) 
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Figure A.2.23: Planar Wheel Graph (500-15000 Vertices, i/2N th Vertex Root) 
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Planar Wheel Graph (Root = VMth) 



y=8905.6356x-1 236944.491 8 
(Robust Regression, MAE = 11814445) 
y=907.1683x-ln(x)+3679284.4656 
(Robust Regression, MAE = 12225130) 
y=3896.6831xln(ln(x))+1 089578.5014 
(Robust Regression, MAE = 11941998) 
y=284980.0044f(x)-1 852803.5444 
(Robust Regression, MAE = 11814445) 



Number of Vertices 



Figure A.2.24: Planar Wheel Graph (500-15000 Vertices, 3/4N th Vertex Root) 




Figure A.2.25: Planar Wheel Graph (500-15000 Vertices, iV th Vertex Root) 
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A. 2. 5 Ordered Face Trisection Graphs (42-4500 Vertices) 



Ordered Face Trisection Graph (Root = %Nth) 



£ 5 
E 

| 4 

l3 3 



y=81 00.2227x-526748.8238 
(Robust Regression, MAE = 3665093) 
y=944.41 57xln(x)+892678.7059 
(Robust Regression, MAE = 3854375) 
y=3765.0791 xln(ln(x))+1 991 29.6348 
(Robust Regression, MAE = 3722815) 
y=7859522.0588f(x)-31 77051 1 .3305 
(Robust Regression, MAE = 8571908) 
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Figure A.2.26: Ordered Face Trisection Graph (42-4500 Vertices, i/W 1 Vertex Root) 



Ordered Face Trisection Graph (Root = V^Nth) 



y=8083.8668x-532081 .8351 
(Robust Regression, MAE = 1225056) 
y=940.1279xln(x)+947099.6558 
(Robust Regression, MAE = 1414951) 
y=3754.8456xln(ln(x))+21 3679.7975 
(Robust Regression, MAE = 1285655) 
y=9051 043.4231 f(x)-391 34892. 
(Robust Regression, MAE = 5953908) 
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Figure A. 2. 27: Ordered Face Trisection Graph (42-4500 Vertices, 1 /2N th Vertex Root) 
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Ordered Face Trisection Graph (Root = %Nth) 



y=8082.7857x-551108.1823 
(Robust Regression, MAE = 1553096) 
y=941 .6839xln(x)+90641 2.71 69 
(Robust Regression, MAE = 1725039) 
y=3758.4879xln(ln(x))+1 81978.9652 
(Robust Regression, MAE = 1600865) 
y=7612561.0683f(x)-30949787.0304 
(Robust Regression, MAE = 7000747) 
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Figure A.2.28: Ordered Face Trisection Graph (42-4500 Vertices, 3/ 4 jV th Vertex Root) 



x -|q 7 Ordered Face Trisection Graph (Root = Nth) 

10p 

y=8064.7096x-529030.8489 

(Robust Regression, MAE = 1406122) 

y=938.01 38xln(x)+941 569.7543 

(Robust Regression, MAE = 1598605) 




Figure A.2.29: Ordered Face Trisection Graph (42-4500 Vertices, iV th Vertex Root) 
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A. 2. 6 Ordered Face Trisection Graphs (500-15000 Vertices) 



200 



Ordered Face Trisection Graph (Root = 1st) 




y=7891.61x-575857.2991 
(Robust Regression, MAE = 6278093) 
y=805.2601xln(x)+3742658.4879 
(Robust Regression, MAE = 6659470) 
y=3459.1993xln(ln(x))+1423122.711 
(Robust Regression, MAE = 6351021) 
y=441 04825.1 924f(x)-321 91 0595.5889 
(Robust Regression, MAE = 14929242) 



15000 
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Figure A.2.30: Ordered Face Trisection Graph (500-15000 Vertices, 1 st Vertex Root) 



Ordered Face Trisection Graph (Root = %Nth) 




y=8081 .2557X-655760.7728 
(Robust Regression, MAE = 111 20304) 
y=825.1752xln(x)+3685699.8966 
(Robust Regression, MAE = 11551287) 
y=3541 .4578xln(ln(x))+1379440.561 3 
(Robust Regression, MAE = 11233880) 
_ y=32527885.8389f(x)-1 74353231 .6394 
(Robust Regression, MAE = 23502400) 



15000 



Number of Vertices 



Figure A.2.31: Ordered Face Trisection Graph (500-15000 Vertices, i/4iV th Vertex Root) 
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Ordered Face Trisection Graph (Root = V^Nth) 



y=8050.593x-554860.8856 
(Robust Regression, MAE = 12676386) 
y=820.1 683x-ln(x)+391 431 1 .01 06 
(Robust Regression, MAE = 13071826) 
y=3523.1 132xln(ln(x))+1 550764.7997 
(Robust Regression, MAE = 12785937) 
y=2581 7734.91 62f(x)-1 360981 67.6957 
(Robust Regression, MAE = 28158443) 
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Figure A.2.32: Ordered Face Trisection Graph (500-15000 Vertices, !/2iV th Vertex Root) 




Figure A.2.33: Ordered Face Trisection Graph (500-15000 Vertices, 3/ 4 iV th Vertex Root) 
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Ordered Face Trisection Graph (Root = Nth) 



y=8036.6041x-531732.972 
(Robust Regression, MAE = 10363658) 
y=820.3067x-ln(x)+382621 6. 1046 
(Robust Regression, MAE = 10799158) 
y=3520.8591xln(ln(x))+1 514243.1503 
(Robust Regression, MAE = 10480651) 
y=324231 76.0836f(x)-1 74996260.3355 
(Robust Regression, MAE = 24069355) 
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Figure A.2.34: Ordered Face Trisection Graph (500-15000 Vertices, N th Vertex Root) 



A. 2. 7 Random Face Trisection Graphs (42-4500 Vertices) 



Random Face Trisection Graph (Root = %Nth) 



y=8091 .3943X-399293.9337 
(Robust Regression, MAE = 21 16531) 
y=943.1005xln(x)+1097710.4967 
(Robust Regression, MAE = 2293644) 
y=3759.821 3xln(ln(x))+356834.21 51 
(Robust Regression, MAE = 2172621) 
y=5505321 .3483f(x)-3252231 8.4525 
(Robust Regression, MAE = 6335956) 
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Figure A. 2. 35: Random Face Trisection Graph (42-4500 Vertices, i/4iV th Vertex Root) 
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x -|q 7 Random Face Trisection Graph (Root = V^Nth) 

10 p 

y=8083.2534x-389587.5396 

(Robust Regression, MAE = 2410211) 
y=943.9179xln(x)+1075168.2255 
(Robust Regression, MAE = 2588612) 
8 "* y=3759.571 4xln(ln(x))+353421 . 1 43 

(Robust Regression, MAE = 2467059) 

y=5011267.3836f(x)-27564589.0049 . j 

(Robust Regression, MAE = 7212265) ; j | ' 
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Figure A.2.36: Random Face Trisection Graph (42-4500 Vertices, !/2iV th Vertex Root) 



x -|q 7 Random Face Trisection Graph (Root = %Nth) 

10 r 

y=8075.997x-35231 6.8048 

(Robust Regression, MAE = 26321 14) 
y=932.2679xln(x)+1339567.3312 
(Robust Regression, MAE = 2679508) 
8 " y=3729.2673x ln(ln(x))+537966.2724 

(Robust Regression, MAE = 2618944) 

y=4963658.1006f(x)-28630341.9944 „ { ll 

(Robust Regression, MAE = 7039375) j 

1 
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Figure A. 2. 37: Random Face Trisection Graph (42-4500 Vertices, 3/ 4 iV th Vertex Root) 



APPENDIX A. EMPIRICAL TESTING FIGURES 



204 




Figure A.2.38: Random Face Trisection Graph (42-4500 Vertices, N th Vertex Root) 




Figure A.2.39: Random Face Trisection Graph (400-4500 Vertices, 3/ 4 iV th Vertex Root) 



APPENDIX A. EMPIRICAL TESTING FIGURES 

A. 2. 8 Random Face Trisection Graphs (500-15000 Vertices) 
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Random Face Trisection Graph (Root = 1st) 




y=7922.197x-3821 13.2727 
(Robust Regression, MAE = 8992789) 
y=81 0.6094xln(x)+3884541 .224 
(Robust Regression, MAE = 9277734) 
y=3475.3501xln(ln(x))+1586704.3533 
(Robust Regression, MAE = 9021704) 
y=26822825.31 46f(x)-26290251 7.6965 
(Robust Regression, MAE = 17181059) 



15000 



Number of Vertices 



Figure A. 2.40: Random Face Trisection Graph (500-15000 Vertices, 1 st Vertex Root) 



Random Face Trisection Graph (Root = %Nth) 



y=7944.4061x-354406.5257 
(Robust Regression, MAE = 7586314) 
y=81 1 ,7595x-ln(x)+39821 22.2202 
(Robust Regression, MAE = 7909207) 
y=3484.1093xln(ln(x))+1 642943.291 
(Robust Regression, MAE = 7629515) 
y=2041 4805.601 4f(x)-1 65454386.5858 
(Robust Regression, MAE = 20201626) 
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Figure A. 2. 41: Random Face Trisection Graph (500-15000 Vertices, 1 /4N th Vertex Root) 
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Random Face Trisection Graph (Root = V^Nth) 



y=7919.2856x-321033.8116 
(Robust Regression, MAE = 10022019) 
y=81 0.7969x-ln(x)+3921 1 92. 1 493 
(Robust Regression, MAE = 10332961) 
y=3475.322x-ln(ln(x))+1 648638.8607 
(Robust Regression, MAE = 10064013) 
y=1 6282536.889f(x)-1 20894676.5095 
(Robust Regression, MAE = 25609920) 
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Figure A.2.42: Random Face Trisection Graph (500-15000 Vertices, 1 /2N th Vertex Root) 



Random Face Trisection Graph (Root = %Nth) 



y=7991.1788x-331750.9645 
(Robust Regression, MAE = 9945233) 
y=809.2268x-ln(x)+4628628.771 8 
(Robust Regression, MAE = 10076222) 
y=3490.0885xln(ln(x))+1 931 510.4532 
(Robust Regression, MAE = 9935005) 
y=1 321 6423.4791f(x)-7781 31 42.1 1 27 
(Robust Regression, MAE = 27912475) 
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Figure A.2.43: Random Face Trisection Graph (500-15000 Vertices, 3/ 4 N th Vertex Root) 
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Random Face Trisection Graph (Root = Nth) 



y=7867.0281x-195418.5141 
(Robust Regression, MAE = 8474118) 
y=807.6787x-ln(x)+3968947.5982 
(Robust Regression, MAE = 8778526) 
y=3459.0259xln(ln(x))+1 726130.0678 
(Robust Regression, MAE = 8523768) 
y=18749032. 1 022f(x)-1 40086497.7054 
(Robust Regression, MAE = 22573254) 




5000 10000 
Number of Vertices 



Figure A.2.44: Random Face Trisection Graph (500-15000 Vertices, N th Vertex Root) 



Random Face Trisection Graph (Root = %Nth, Vertex > 750) 




y=7990 9555x-333817 9979 
(Robust Regression, MAE = 10056748) 
_ y=81 1 .5069xln(x)+4426221 .1 61 5 

(Robust Regression, MAE = 10270388) 
_y=3492.5324xln(ln(x))+1882017.0261 
(Robust Regression, MAE = 10075262) 



5000 10000 
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15000 



Figure A. 2. 45: Random Face Trisection Graph (750-15000 Vertices, 3/iN th Vertex Root) 
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A. 3 Variations in Number of Edges for Sub-Graphs of 
Constant Graph Size and Type 



A. 3.1 Triangular Prism Graphs (14999 Vertices) 



Execution Time of 
14999 Vertex Triangular Prism Graph (Root = 1st) 



y=3235.4624x-1 2631 1 75.2233 
(Robust Regression, MAE = 15541986) 
y=280.7503xln(x)-2255353.7283 
(Robust Regression, MAE = 15542722) 
y=1 321 .31 24xln(ln(x))-7990058.01 85 
(Robust Regression, MAE = 15542137) 




Number of Edges 



Figure A.3.1: Triangular Prism Graph (14999 Vertices, -30000-45000 Edges, 1 st Vertex Root) 
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Execution Time of 
1 4999 Vertex Triangular Prism Graph (Root = %Nth) 



y=3720.0523x-30550301 .21 04 
(Robust Regression, MAE = 14788546) 
y=322.8484xln(x)-1 8641 51 1 .3848 
(Robust Regression, MAE = 14765916) 
y=1 51 9.3069xln(ln(x))-25223079.7981 
(Robust Regression, MAE = 14779177) 




Number of Edges x -| q 4 



Figure A.3.2: Triangular Prism Graph (14999 Vertices, -30000-45000 Edges, !/4iV th Vertex 
Root) 



Execution Time of 
14999 Vertex Triangular Prism Graph (Root = %Nth, 2nd Run) 




(Robust Regression, MAE = 19055515) 
y=1 51 4.8833xln(ln(x))-24304S07.3791 
(Robust Regression, MAE = 19067521) 



Number of Edges 



Figure A.3.3: Triangular Prism Graph (14999 Vertices, -30000-45000 Edges, i/4iV th Vertex 
Root, 2 nd Run) 
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Execution Time of 
1 4999 Vertex Triangular Prism Graph (Root = 1 / 2 Nth) 




(Robust Regression, MAE = 14017703) 



Number of Edges x -| q 4 



Figure A.3.4: Triangular Prism Graph (14999 Vertices, -30000-45000 Edges, 1 /2N th Vertex 
Root) 



Execution Time of 
1 4999 Vertex Triangular Prism Graph (Root = %Nth) 



y=3444.1297x-22281749.844 
(Robust Regression, MAE = 13953239) 
y=298.91 xln(x)-1 1 25651 0.391 9 
(Robust Regression, MAE = 13957438) 
y=1 406.6363xln(ln(x))-1 73501 64.1 695 
(Robust Regression, MAE = 13954722) 




Figure A.3.5: Triangular Prism Graph (14999 Vertices, -30000-45000 Edges, 3/ 4 iV th Vertex 
Root) 
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Execution Time of 
14999 Vertex Triangular Prism Graph (Root = Nth) 




y=1 440.0861xln(ln(x))-1 8386741 .3592 
(Robust Regression, MAE = 14158026) 



Number of Edges x -| q 4 



Figure A.3.6: Triangular Prism Graph (14999 Vertices, -30000-45000 Edges, V th Vertex 
Root) 
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W 2 
£ 



Execution Time of 
15000 Vertex Planar Wheel Graph (Root = 1st) 



_ y=3749.971 9X-3866931 1 .4008 
(Robust Regression, MAE = 16400791) 

_ y=325.351 6xln(x)-266261 96.8223 
(Robust Regression, MAE = 16405925) 

_ y=1 531 .3507xln(ln(x))-33283099.8279 
(Robust Regression, MAE = 16402689) 




Number of Edges 



4.5 

x10 4 



Figure A.3.7: Planar Wheel Graph (15000 Vertices, -30000-45000 Edges, 1 st Vertex Root) 



W 2 
E 



Execution Time of 
1 5000 Vertex Planar Wheel Graph (Root = KNth) 



_ y=3762.841 5X-376801 65.4746 
(Robust Regression, MAE = 17279038) 

_ y=326.481 1xln(x)-25598802.7214 
(Robust Regression, MAE = 17281242) 

_ y=1 536.6251 xln(ln(x))-32276275.351 3 
(Robust Regression, MAE = 17279758) 




Number of Edges 



4.5 

x 10 4 



Figure A.3.8: Planar Wheel Graph (15000 Vertices, -30000-45000 Edges, i/47V th Vertex Root) 
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uj 1.5 



Execution Time of 
1 5000 Vertex Planar Wheel Graph (Root = KNth) 



_ y=3606.1 261 x-33670734.0642 
(Robust Regression, MAE = 13161375) 

_ y=31 2.8497xln(x)-22082047.3933 
(Robust Regression, MAE = 13174988) 

_ y=1 472.5658xln(ln(x))-28487754.9254 
(Robust Regression, MAE = 13166686) 




Number of Edges 



4.5 

x 10 4 



Figure A.3.9: Planar Wheel Graph (15000 Vertices, -30000-45000 Edges, i/2.ZV th Vertex Root) 



Execution Time of 
1 5000 Vertex Planar Wheel Graph (Root = YMtb) 



_ y=3575.931 1 x-32648594.7505 
(Robust Regression, MAE = 12951990) 

_ y=31 0.31 54xln(x)-21 1 881 22.1 99 
(Robust Regression, MAE = 12965026) 

_ y=1 460.4087xln(ln(x))-27523052.5501 
(Robust Regression, MAE = 12957054) 



Number of Edges 



4.5 

x10 4 



Figure A.3.10: Planar Wheel Graph (15000 Vertices, -30000-45000 Edges, 3/ 4 iV th Vertex 
Root) 
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Execution Time of 
15000 Vertex Planar Wheel Graph (Root = Nth) 



_ y=3448.9977x-2931 2676.7445 
(Robust Regression, MAE = 16315376) 

_ y=299.2744xln(x)-1 82491 36.5659 
(Robust Regression, MAE = 16316008) 

_ y=1408.51 18xln(ln(x))-24364357.886 
(Robust Regression, MAE = 16315450) 




Number of Edges 
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x 10 4 



Figure A.3.11: Planar Wheel Graph (15000 Vertices, -30000-45000 Edges, N th Vertex Root) 
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Figure A.3.12: Ordered Face Trisection Graph (14999 Vertices, -30000-45000 Edges, l 1 
Vertex Root) 
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W 1.8 
£ 



Lu 1.4 



Execution Time of 
14999 Vertex Ordered Face Trisection Graph (Root = %Nth) 



_ y=2786.751 9x-1 033961 3.2386 
(Robust Regression, MAE = 22395179) 

_ y=241 .8279xln(x)-1 406778.446 
(Robust Regression, MAE = 22392774) 

_ y=1 1 38.0979xln(ln(x))-63441 31 .401 3 
(Robust Regression, MAE = 22394051) 



Number of Edges 



4.5 

x 10 4 



Figure A. 3. 13: Ordered Face Trisection Graph (14999 Vertices, 
Vertex Root) 



-30000-45000 Edges, y±N 



ih 



W 1.8 
E 



Execution Time of 
14999 Vertex Ordered Face Trisection Graph (Root = %Nth, 2nd Run) 



y=2703.9875x-7020296.6265 
(Robust Regression, MAE = 16173935) 
y=234.591 2xln(x)+1 667886.6725 
(Robust Regression, MAE = 16181328) 
_y=1104.1929xln(ln(x))-3134863.2424 
(Robust Regression, MAE = 16176750) 



Number of Edges 



4.5 

x 10 4 



Figure A. 3. 14: Ordered Face Trisection Graph (14999 Vertices, 
Vertex Root, 2 nd Run) 



-30000-45000 Edges, 1/4N 



ih 
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W 1.8 - 
£ 



uj 1.4 - 



Execution Time of 
14999 Vertex Ordered Face Trisection Graph (Root = V^Nth) 



_ y=2783.3346x-1 03391 1 1 .4087 
(Robust Regression, MAE = 18556445) 

_ y=241 ,5258xln(x)-1 41 51 56. 1 575 
(Robust Regression, MAE = 18557985) 

_ y=1 1 36.6891 xln(ln(x))-6347585.921 2 
(Robust Regression, MAE = 18556870) 




Number of Edges 



4.5 

x 10 4 



Figure A.3.15: Ordered Face Trisection Graph (14999 Vertices, -30000-45000 Edges, i/W 
Vertex Root) 




Figure A.3.16: Ordered Face Trisection Graph (14999 Vertices, -30000-45000 Edges, 3/ 4 A^' 
Vertex Root) 
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Execution Time of 
14999 Vertex Ordered Face Trisection Graph (Root = Nth) 



y=2768.0523x-9755928.8467 
(Robust Regression, MAE = 20754869) 
y=240.2139xln(x)-886331.7434 
(Robust Regression, MAE = 20756816) 
y=1 130.4741xln(ln(x))-5788546.961 4 
(Robust Regression, MAE = 20755480) 




Number of Edges x -| q 4 



uj 1.5 



Figure A.3.17: Ordered Face Trisection Graph (14999 Vertices, -30000-45000 Edges, TV 1 
Vertex Root) 
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Figure A.3.18: Random Face Trisection Graph (14999 Vertices, -30000-45000 Edges, 1 ; 
Vertex Root) 
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uj 1.5 



Execution Time of 
14999 Vertex Random Face Trisection Graph (Root = %Nth) 



_ y=2975.0624x-1 747801 6.0473 
(Robust Regression, MAE = 16791247) 

_y=258.1562xln(x)-7936753.9101 
(Robust Regression, MAE = 16794352) 

_ y=1 21 4.9779xln(ln(x))-1 321 061 5.8561 
(Robust Regression, MAE = 16792280) 




Number of Edges 



4.5 

x 10 4 



Figure A.3.19: Random Face Trisection Graph (14999 Vertices, -30000-45000 Edges, i/47V th 
Vertex Root) 



Execution Time of 
14999 Vertex Random Face Trisection Graph (Root = V^Nth) 



_ y=2990.41 05x-1 7949424.2302 
(Robust Regression, MAE = 14939222) 
y=259.4551xln(x)-8345934.171 1 
(Robust Regression, MAE = 14948367) 

_ y=1 221 .1 81 5xln(ln(x))-1 3654385.6694 
(Robust Regression, MAE = 14942765) 




Number of Edges 



4.5 

x 10 4 



Figure A.3.20: Random Face Trisection Graph (14999 Vertices, -30000-45000 Edges, i/2N th 
Vertex Root) 



APPENDIX A. EMPIRICAL TESTING FIGURES 



uj 1.5 - 



Execution Time of 
14999 Vertex Random Face Trisection Graph (Root = %Nth) 



_ y=2990.0353x-1 80491 43.31 56 
(Robust Regression, MAE = 15082308) 

_y=259.4265xln(x)-8449139.9208 
(Robust Regression, MAE = 15083301) 

_ y=1 221 .0351 xln(ln(x))-1 375561 5.6929 
(Robust Regression, MAE = 15082542) 



Number of Edges 



4.5 

x 10 4 



Figure A.3.21: Random Face Trisection Graph (14999 Vertices, -30000-45000 Edges 
Vertex Root) 




Figure A.3.22: Random Face Trisection Graph (14999 Vertices, -30000-45000 Edges 
Vertex Root) 
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A. 4 Variations in Number of Edges for Sub-Graphs of 
Constant Graph Size and Type — Effects on Numbers 
of Conflicts and Mean Segment Depth 

A. 4.1 Triangular Prism Graphs 



Segment Conflicts for Biconnected Sub-Graphs of 
14999 Vertex Triangular Prism 
Graph (Root = 1st Vertex) 



3.5 4 
Number Of Edges 



4.5 

x10 4 



Mean Segment Depth for Biconnected Sub-Graphs of 
14999 Vertex Triangular Prism 
Graph (Root = 1st Vertex) 




Change in Mean Segment Depth for Biconnected Sub-Graphs of 
14999 Vertex Triangular Prism 
Graph (Root = 1st Vertex) 

15r 



3.5 4 
Number Of Edges 

Change in Change in Mean Segment Depth 
for Biconnected Sub-Graphs of 
14999 Vertex Triangular Prism 
Graph (Root = 1st Vertex) 




3.5 4 
Number Of Edges 



3.5 4 
Number Of Edges 



4.5 

x 10 4 



Figure A. 4.1: Mean Segment Depth for Biconnected Sub-Graphs of Triangular Prism Graph 
(14999 Vertices, -30000-45000 Edges, 1 st Vertex Root) 
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Segment Conflicts for Biconnected Sub-Graphs of 
14999 Vertex Triangular Prism 
Graph (Root = 1 / 2 Nth Vertex) 



Mean Segment Depth for Biconnected Sub-Graphs of 
14999 Vertex Triangular Prism 
Graph (Root = 1 / 2 Nth Vertex) 
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14999 Vertex Triangular Prism 
Graph (Root = 1 / 2 Nth Vertex) 

15 r 




.!= O) 
» m 



3.5 4 
Number Of Edges 



3.5 4 4.5 

Number Of Edges x ^g 4 

Change in Change in Mean Segment Depth 
for Biconnected Sub-Graphs of 
14999 Vertex Triangular Prism 
Graph (Root = J4Nth Vertex) 
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Figure A. 4. 2: Mean Segment Depth for Biconnected Sub-Graphs of Triangular Prism Graph 
(14999 Vertices, -30000-45000 Edges, i/2iV th Vertex Root) 
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Segment Conflicts for Biconnected Sub-Graphs of 
14999 Vertex Triangular Prism 
Graph (Root = VMth Vertex) 
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Mean Segment Depth for Biconnected Sub-Graphs of 
14999 Vertex Triangular Prism 
Graph (Root = KNth Vertex) 
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Change in Mean Segment Depth for Biconnected Sub-Graphs of 
14999 Vertex Triangular Prism 
Graph (Root = VMth Vertex) 

10 



Change in Change in Mean Segment Depth 
for Biconnected Sub-Graphs of 
14999 Vertex Triangular Prism 
Graph (Root = KNth Vertex) 




3.5 4 
Number Of Edges 



Figure A. 4. 3: Mean Segment Depth for Biconnected Sub-Graphs of Triangular Prism Graph 
(14999 Vertices, -30000-45000 Edges, 3/ 4 iV th Vertex Root) 




Figure A. 4. 4: Mean Segment Depth for Biconnected Sub-Graphs of Triangular Prism Graph 
(14999 Vertices, -30000-45000 Edges, iV th Vertex Root) 
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Segment Conflicts for Biconnected Sub-Graphs of 

1 5000 Vertex Planar Wheel 
x -|o 4 Graph (Root = 1st Vertex) 



Mean Segment Depth for Biconnected Sub-Graphs of 
15000 Vertex Planar Wheel 
Graph (Root = 1st Vertex) 
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Change in Change in Mean Segment Depth 
for Biconnected Sub-Graphs of 
15000 Vertex Planar Wheel 
Graph (Root = 1st Vertex) 
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Figure A. 4. 5: Mean Segment Depth for Biconnected Sub-Graphs of Planar Wheel Graph 
(14999 Vertices, -30000-45000 Edges, 1 st Vertex Root) 



Segment Conflicts for Biconnected Sub-Graphs of 

1 5000 Vertex Planar Wheel 
x -i o 4 Graph (Root = VMlh Vertex) 



Mean Segment Depth for Biconnected Sub-Graphs of 
15000 Vertex Planar Wheel 
Graph (Root = '/.Nth Vertex) 
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Change in Mean Segment Depth for Biconnected Sub-Graphs of 
1 5000 Vertex Planar Wheel 
Graph (Root = '/.Nth Vertex) 
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Change in Change in Mean Segment Depth 
for Biconnected Sub-Graphs of 
15000 Vertex Planar Wheel 
Graph (Root = '/.Nth Vertex) 
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Figure A. 4. 6: Mean Segment Depth for Biconnected Sub-Graphs of Planar Wheel Graph 
(14999 Vertices, -30000-45000 Edges, i/4^V th Vertex Root) 
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Segment Conflicts for Biconnected Sub-Graphs of 

1 5000 Vertex Planar Wheel 
x -i o 4 Graph (Root = V^Nth Vertex) 



Mean Segment Depth for Biconnected Sub-Graphs of 
15000 Vertex Planar Wheel 
Graph (Root = J4Nth Vertex) 
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Change in Mean Segment Depth for Biconnected Sub-Graphs of 
1 5000 Vertex Planar Wheel 
Graph (Root = KNth Vertex) 
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Change in Change in Mean Segment Depth 
for Biconnected Sub-Graphs of 
15000 Vertex Planar Wheel 
Graph (Root = J4Nth Vertex) 
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Figure A. 4. 7: Mean Segment Depth for Biconnected Sub-Graphs of Planar Wheel Graph 
(14999 Vertices, -30000-45000 Edges, i/2iV th Vertex Root) 
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Graph (Root = KNth Vertex) 
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Change in Mean Segment Depth for Biconnected Sub-Graphs of 
1 5000 Vertex Planar Wheel 
Graph (Root = VMth Vertex) 
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Change in Change in Mean Segment Depth 
for Biconnected Sub-Graphs of 
15000 Vertex Planar Wheel 
Graph (Root = KNth Vertex) 
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Figure A. 4. 8: Mean Segment Depth for Biconnected Sub-Graphs of Planar Wheel Graph 
(14999 Vertices, -30000-45000 Edges, 3/ 4 iV th Vertex Root) 
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Segment Conflicts for Biconnected Sub-Graphs of Mean Segment Depth for Biconnected Sub-Graphs of 

1 5000 Vertex Planar Wheel 1 5000 Vertex Planar Wheel 

<-|0 4 Graph (Root = Nth Vertex) Graph (Root = Nth Vertex) 
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Change in Mean Segment Depth for Biconnected Sub-Graphs of 
1 5000 Vertex Planar Wheel 
Graph (Root = Nth Vertex) 
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Change in Change in Mean Segment Depth 
for Biconnected Sub-Graphs of 
15000 Vertex Planar Wheel 
Graph (Root = Nth Vertex) 
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Figure A. 4. 9: Mean Segment Depth for Biconnected Sub-Graphs of Planar Wheel Graph 
(14999 Vertices, -30000-45000 Edges, iV th Vertex Root) 



A. 4. 3 Ordered Face Trisection Graphs 



Segment Conflicts for Biconnected Sub-Graphs of 
14999 Vertex Ordered Face Trisection 
Graph (Root = 1st Vertex) 
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14999 Vertex Ordered Face Trisection 
Graph (Root = 1st Vertex) 
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Change in Mean Segment Depth for Biconnected Sub-Graphs of 
14999 Vertex Ordered Face Trisection 
x -|o" 3 Graph (Root = 1st Vertex) 
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14999 Vertex Ordered Face Trisection 
n 4 Graph (Root = 1st Vertex) 
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Figure A. 4. 10: Mean Segment Depth for Biconnected Sub-Graphs of Ordered Face Trisection 
Graph (14999 Vertices, -30000-45000 Edges, 1 st Vertex Root) 
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Segment Conflicts for Biconnected Sub-Graphs of 
14999 Vertex Ordered Face Trisection 
Graph (Root = '/.Nth Vertex) 
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Change in Mean Segment Depth for Biconnected Sub-Graphs of 
14999 Vertex Ordered Face Trisection 
Graph (Root = '/.Nth Vertex) 
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Mean Segment Depth for Biconnected Sub-Graphs of 
14999 Vertex Ordered Face Trisection 
Graph (Root = '/.Nth Vertex) 
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Figure A. 4. 11: Mean Segment Depth for Biconnected Sub-Graphs of Ordered Face Trisection 
Graph (14999 Vertices, -30000-45000 Edges, i/4N th Vertex Root) 




Figure A. 4. 12: Mean Segment Depth for Biconnected Sub-Graphs of Ordered Face Trisection 
Graph (14999 Vertices, -30000-45000 Edges, i/2N th Vertex Root) 
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Segment Conflicts for Biconnected Sub-Graphs of 
14999 Vertex Ordered Face Trisection 
Graph (Root = %Nth Vertex) 




3.5 4 
Number Of Edges 



Change in Mean Segment Depth for Biconnected Sub-Graphs of 
14999 Vertex Ordered Face Trisection 
Graph (Root = %Nth Vertex) 
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Mean Segment Depth for Biconnected Sub-Graphs of 
14999 Vertex Ordered Face Trisection 
Graph (Root = %Nth Vertex) 
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for Biconnected Sub-Graphs of 
14999 Vertex Ordered Face Trisection 
g- 3 Graph (Root = %Nth Vertex) 
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Figure A. 4. 13: Mean Segment Depth for Biconnected Sub-Graphs of Ordered Face Trisection 
Graph (14999 Vertices, -30000-45000 Edges, 3/47V th Vertex Root) 
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for Biconnected Sub-Graphs of 
14999 Vertex Ordered Face Trisection 
g- 3 Graph (Root = Nth Vertex) 
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Figure A. 4. 14: Mean Segment Depth for Biconnected Sub-Graphs of Ordered Face Trisection 
Graph (14999 Vertices, -30000-45000 Edges, N th Vertex Root) 
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Segment Conflicts for Biconnected Sub-Graphs of 
14999 Vertex Random Face Trisection 
Graph (Root = 1st Vertex) 
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Mean Segment Depth for Biconnected Sub-Graphs of 
1 4999 Vertex Random Face Trisection 
Graph (Root = 1st Vertex) 




Change in Mean Segment Depth for Biconnected Sub-Graphs of 
14999 Vertex Random Face Trisection 
x -|o" 3 Graph (Root = 1st Vertex) 
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1 4999 Vertex Random Face Trisection 
g- 3 Graph (Root = 1st Vertex) 
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Figure A. 4. 15: Mean Segment Depth for Biconnected Sub-Graphs of Random Face Trisection 
Graph (14999 Vertices, -30000-45000 Edges, 1 st Vertex Root) 
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Mean Segment Depth for Biconnected Sub-Graphs of 
1 4999 Vertex Random Face Trisection 
Graph (Root = '/.Nth Vertex) 
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Figure A. 4. 16: Mean Segment Depth for Biconnected Sub-Graphs of Random Face Trisection 
Graph (14999 Vertices, -30000-45000 Edges, y±N th Vertex Root) 
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Segment Conflicts for Biconnected Sub-Graphs of 
14999 Vertex Random Face Trisection 
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Graph (Root = '^Nth Vertex) 
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Figure A. 4. 17: Mean Segment Depth for Biconnected Sub-Graphs of Random Face Trisection 
Graph (14999 Vertices, -30000-45000 Edges, i/2N th Vertex Root) 
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Figure A. 4. 18: Mean Segment Depth for Biconnected Sub-Graphs of Random Face Trisection 
Graph (14999 Vertices, -30000-45000 Edges, 3/ 4 7V th Vertex Root) 
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Segment Conflicts for Biconnected Sub-Graphs of 
14999 Vertex Random Face Trisection 
Graph (Root = Nth Vertex) 



Mean Segment Depth for Biconnected Sub-Graphs of 
1 4999 Vertex Random Face Trisection 
Graph (Root = Nth Vertex) 
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Figure A. 4. 19: Mean Segment Depth for Biconnected Sub-Graphs of Random Face Trisection 
Graph (14999 Vertices, -30000-45000 Edges, N th Vertex Root) 



A. 5 Variations in Size of Permutable, Flippable Graphs 



gf 1.5 - 

e 



Execution Time of 
Permutable Flippable Graph (Root = 1st) 



y=6253.8876x-1 10353.9856 
(Robust Regression, MAE = 8793283) 
y=636.3407xln(x)+3487637.71 26 
(Robust Regression, MAE = 8890456) 
y=2731 .0054xln(ln(x))+ 1 634797.1 006 
(Robust Regression, MAE = 8804118) 
y=58743563804.5839f(x)-1 1 741 351 5478.2791 
(Robust Regression, MAE = 20124000) 
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Figure A.5.1: Permutable, Flippable Graph (1002-15002 Vertices, 1 st Vertex Root) 
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Execution Time of 
Permutable Flippable Graph (Root = VMth) 



y=6227.1241x+202116.8022 
(Robust Regression, MAE = 9588673) 
y=633.1605xln(x)+3846550.9805 
(Robust Regression, MAE = 9777305) 
y=2720.0357xln(ln(x))+ 1 950326.5322 
(Robust Regression, MAE = 9642010) 
y=5797934331 2.9932f(x)-1 1 5884097882.6946 
(Robust Regression, MAE = 19954875) 



«f 1.5 - 
E 
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Figure A.5.2: Permutable, Flippable Graph (1002-15002 Vertices, Vertex Root) 



Execution Time of 
Permutable Flippable Graph (Root = V^Nth) 



y=6232.3837x+166905.4313 
(Robust Regression, MAE = 10154894) 
y=633.9122xln(x)+3788225.997 
(Robust Regression, MAE = 10320925) 
y=2723.0536xln(ln(x))+ 1 902908.0047 
(Robust Regression, MAE = 10201495) 
y=5831 51 751 65.0976f(x)-1 1 6555472795.8574 
(Robust Regression, MAE = 20405195) 
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Figure A.5.3: Permutable, Flippable Graph (1002-15002 Vertices, i/2iV th Vertex Root) 
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Execution Time of 
Permutable Flippable Graph (Root = %Nth) 



y=6216.6907x+212112.1727 
(Robust Regression, MAE = 9775322) 
y=633.1586xln(x)+3798272.3592 
(Robust Regression, MAE = 9943227) 
y=2716.943xln(ln(x))+1 939029.7432 
(Robust Regression, MAE = 9822890) 
y=58731 399586.7721f(x)-1 1 7387783565.1 602 
(Robust Regression, MAE = 20167180) 
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Figure A.5.4: Permutable, Flippable Graph (1002-15002 Vertices, 3/ 4 jV th Vertex Root) 



Execution Time of 
Permutable Flippable Graph (Root = Nth) 



y=6160.0341x+146074.402 
(Robust Regression, MAE = 9766313) 
y=627.71 39xln(x)+36541 90.031 8 
(Robust Regression, MAE = 9882703) 
y=2692.0026xln(ln(x))+ 1 84871 3.0055 
(Robust Regression, MAE = 9796296) 
y=581 62831 903.2335f(x)-1 1 6251 404936.5392 
(Robust Regression, MAE = 19937485) 
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Figure A.5.5: Permutable, Flippable Graph (1002-15002 Vertices, N th Vertex Root) 



Appendix B 

Configuration used for Empirical 
Testing 

The tests were performed on the following hardware and software configuration: 

• Toshiba Satellite Pro Laptop A210; 

• AMD Athlon 64 Dual-Core Processors, 1.8GHz; 

• 2Gb RAM; and 

• Windows Vista Business (6.0, Build 6002) 

The software was written in Java and run from the Eclipse Platform; this choice was made as 
there is an inbuilt functionality to redirect the console output to a file and therefore the garbage 
collection output provided using the PrintGCDetails VM option will output inline with the 
normal program output. The following Eclipse configuration was used: 

• Eclipse version: 3.4.2 (Build id: M20090211-1700); 

• Java Virtual Machine: Java Development Kit 1.6.0_11; 

• VM arguments: -server -Xmsl536M -Xmxl536M -XX:+PrintGCDetails; 

• Console allocated and redirected to file. 

During execution the laptop was run in flight mode with all processes and services, not required 
for minimal operating system functionality, stopped to minimise external influences. 
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Clock Resolution Testing 



C.l Clock Resolution Test Code 



import java. util .*; 

public class ClockTest { 

public static final int REPETITIONS = 10000000; 

public static void main( String [] args) { 

/* 

* Fill the array with measurements between clock cycles 

*/ 

final long[] data = new long [REPETITIONS ] ; 
for ( int i = 0; i < REPETITIONS; i++ ) { 

long startTime = System . nanoTime ( ) ; 

long endTime = System . nanoTime ( ) ; 

data[i] = endTime — startTime; 

} 

* Compile frequency data from the previous timing data. 

*/ 

HashMap<Long , Integer > frequencyData 

= new HashMap<Long , Integer >() ; 
for ( int i = 0; i < REPETITIONS; i-H- ) { 

if ( frequencyData . containsKey ( data [ i ] ) ) 
frequencyData . put ( 
data [ i ] , 

frequencyData . get ( data [ i ] ) + 1 

); 

else frequencyData . put ( data [ i ] , 1 ); 

} 

Long[] times = frequencyData . keySet ( ) ,toArray( 

new Long [ frequencyData.keySet().size() ] 

); 

Arrays . sort ( times ) ; 
boolean first = true; 

/* 

* Output the data in a MATLAB Friendly format . 

* / 

System . out . print ( ' [ 1 ) ; 
for ( long time: times ) { 

if ( first ) first = false; 

else System . out . print ( " ; " ) ; 

System . out . print ( " " + time + 
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" " + frequencyData . get ( time ) ) ; 

} 

System .out.println( 1 ] 1 ); 

} 

} 



C.2 Clock Resolution Raw Data 
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Java Source Code 



D.l Data Structure Files 

D.l.l mgtaylor.datastructures.AccessibleUnmodifiableLinkList 

package mgtaylor . datastructures ; 

import java . util . ConcurrentModificationException ; 

/ * * 

* A linked list that makes the (normally private) data structures 

* containing links between elements public and adds functionality 

* to append elements to head/ tailwards of a given list data 

* structure . 

* ©author Martyn G. Taylor 

* ©param <E> 

*/ 

public class AccessibleUnmodifiableLinkList <E> 
extends UnmodifiableLinkList <E> { 

/ * * 
* 

17 * ©return 

18 */ 

public ListElement getHeadContainer ( ) { return head; } 

/* * 
* 

* ©return ListElement 

* / 

public ListElement get TailCont ainer ( ) { return tail ; } 

/* * 

* Overrides the superclass ' findElement method to make it 

29 * publicly accessible. 

30 * ©param element 

* ©return ListElement 

*/ 

©Override 

34 public ListElement findElement ( final E element ) { 

35 return super . findElement ( element ); 

} 



240 
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* Qparam listElement 

* @param element 

* / 

public void appendHeadwardsOf ( ListElement tailwardsElement , E element ) { 
if ( size () = | | tailwardsElement = head ) 

addHead ( element ) ; 
else { 

long change = changes ; 

ListElement le = new ListElement ( element ) ; 

ListElement headwardsElement = t ailwardsElement . getHeadwards ( ) ; 

le . setTailwards ( tailwardsElement ) ; 

le . setHeadwards ( headwardsElement ); 

tailwardsElement . setHeadwards ( le ); 

headwardsElement . setTailwards ( le ); 

size H — h; 

if ( change != changes ) 

throw new Concurrent Modificat ionExcept ion () ; 
incrementChange ( ) ; 

} 

} 

/* * 
* 

* Oparam headwardsElement 

* @param element 

*/ 

public void appendTailwardsOf ( ListElement headwardsElement , E element ) { 
if ( size () = | | headwardsElement = tail ) 

addTail ( element ) ; 
else { 

long change = changes ; 

ListElement le = new ListElement ( element ) ; 

ListElement tailwardsElement = headwardsElement . getTailwards () ; 

le . setTailwards ( tailwardsElement ) ; 

le . setHeadwards ( headwardsElement ); 

tailwardsElement . setHeadwards ( le ); 

headwardsElement . setTailwards ( le ); 

size H — h; 

if ( change != changes ) 

throw new ConcurrentModificationException ( ) ; 
incrementChange ( ) ; 

} 

} 

} 
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D.1.2 mgtaylor.datastructures.LinkList 



package mgtaylor . datastructures ; 
import java. util . Iterator ; 

import java . util . ConcurrentModificationException : 



17 
IS 



<p>An extension of the UnmodifiableLinkList structure that adds 
functionality to:</p> 
<ul> 

<li>Remove a given element from the list.</li> 

<li>Remove the head element from the list.</li> 

<li>Remove the tail element from the list.</li> 

<li>Clear (remove all elements from) the list .</li> 

<li>Remove the element at the current iterator pos i t i o n . </ 1 i > 

</ul> 

©author Martyn G. Taylor 

@see mgtaylor . datastructures . UnmodifiableLinkList UnmodifiableLinkList 
@param <E> 



*/ 

public class LinkList<E> extends Unmodif iableL inkList <E> 
implements Iterable<E> { 



25 
26 



/* * 

* Constructor to set List to be modifiable . 

* / 

public LinkListQ { 
super ( ) ; 

this . isModifiable = true; 

} 



33 
34 



3 7 
38 



/* * 

* Removes a given list element from the list . 

* Oparam 1 e 

* ©return ListElementStore — A container used to store the 

* current and next elements of the list to keep a valid 

* state for an iterator. 

*/ 

protected ListElementStore removeElement ( ListElement le ) { 
if ( le = null ) 
return null ; 



15 
16 



19 
50 



51 
55 



58 
59 



if ( le = head && le = tail ) { 
head = tail = null; 
size = ; 

return new ListElementStore ( null, null ); 
} else if ( le = head ) { 

head = head . getTailwards ( ) ; 
if ( head != null ) 

head . setHeadwards ( null ); 
le . setTailwards ( null ) ; 
size ; 

return new ListElementStore ( null, head ); 
} else if ( le = tail ) { 

tail = t a i 1 . getHeadwards ( ) ; 
le . setHeadwards ( null ); 
if ( tail != null ) 

t a i 1 . set Tail wards ( null ); 
size ; 

return new ListElementStore ( tail , null ); 
} else { 

final ListElement current = le . getHeadwards ( ) 
final ListElement next = le . getTailwards ( ) 
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current . setTailwards ( next ); 
next . setHeadwards ( current ); 
le . setHeadwards ( null ); 

66 le . setTailwards ( null ) ; 

67 size ; 

return new ListElementStore ( current , next ); 

} 

} 

/** 

* Removes all elements from the list . 

* ©throws ConcurrentModificationException Thrown if the list is 

* modified during the execution of this method. 

* ©throws IllegalArgumentException Thrown if the list cannot 

* be modified . 

78 */ 

79 public void clear () { 
if ( ! isModifiable ) 

throw new IllegalArgumentException ( 

82 " mgtaylor . datastructures . LinkList . clear () - " + 

83 "List is not modifiable." ); 

final long change = changes; 

head = tail = null; 

size = ; 

isModifiable = true; 

if ( change != changes ) 

throw new ConcurrentModificationException ( 

"mgtaylor . datastructures . LinkList . clear () " ) ; 

94 incrementChange ( ) ; 

95 } 

/** 

98 * Removes a given element from the list . 

99 * ©param element 

100 * ©return boolean — Whether the element was successfully 

101 * found and removed . 

102 * ©throws ConcurrentModificationException Thrown if the list is 

103 * modified during the execution of this method. 

104 * ©throws IllegalArgumentException Thrown if the list cannot 

105 * be modified . 

106 * / 

107 public boolean remove ( final E element ) { 

108 if ( element = null ) 

109 throw new Illegal ArgumentException ( "Null is an invalid argument." ) 
no if ( ! isModifiable ) 

in throw new IllegalArgumentException ( "List has been appended with an 
Unmodif iableLinkList and items cannot be removed from the list." ); 

final long change = changes; 

final boolean found = removeElement ( findElement ( element ) ) != null; 

117 if ( change != changes ) 

118 throw new ConcurrentModificationException ( ) ; 
no incrementChange ( ) ; 

121 return found ; 

122 } 

124 /** 

125 * Removes the head element from the list . 

126 * ©return E — The removed element . 
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127 * @throws ConcurrentModificationException Thrown if the list is 

128 * modified during the execution of this method. 

129 * ©throws IllegalArgumentException Thrown if the list cannot 

130 * be modified . 

131 * / 

132 public E removeHeadQ { 

133 if ( ! isModifiable ) 

134 throw new IllegalArgumentException ( "List is not modifiable." ) 

135 final long change = changes ; 

136 final E element ; 

137 if ( size > ) { 

138 element = head . getElement ( ) ; 

139 if ( size = 1 ) 

140 head = tail = null; 

141 else { 

142 head = head . get Tailwards () ; 

143 head . setHeadwards ( null ); 

144 } 

145 size ; 

146 } else 

147 element = null ; 

148 if ( change != changes ) 

149 throw new ConcurrentModificationException ( ) ; 

150 incrementChange ( ) ; 

151 return element ; 

152 } 

154 /** 

155 * Removes the tail element from the list . 

156 * ©return E — The removed element . 

157 * ©throws ConcurrentModificationException Thrown if the list is 

158 * modified during the execution of this method. 

159 * ©throws IllegalArgumentException Thrown if the list cannot 

160 * be modified . 

161 * / 

162 public E removeTailQ { 

163 if ( ! isModifiable ) 

164 throw new IllegalArgumentException ( "List is not modifiable." ) 

165 final long change = changes ; 

166 final E element ; 

167 if(size>0){ 

168 element = t a i 1 . get Element () ; 

169 if ( size = 1 ) 

170 head = tail = null; 

171 else { 

172 tail = t ai 1 . getHeadwards ( ) ; 

173 t a i 1 . set Tail wards ( null ); 

174 } 

175 size ; 

176 } else 

177 element = null ; 

178 if ( change != changes ) 

179 throw new Concurrent ModificationExcept ion () ; 

180 incrementChange ( ) ; 
return element ; 



1S1 
1S2 



} 



184 /** 

185 * <p>An iterator to loop over the list from head— to — t a i 1 . </p> 

186 * <p>Overrides the iterator from the super — class to add 

187 * functionality to remove elements from the list.</p> 

188 * ©return Iterator<E> 

189 * Osee mgt ay lor . dat as t r uc t ur es . Unmodif iableLinkList#i t e r a t o r ( ) 

190 * Unmodif iableLinkList . i t e r a t o r ( ) 

191 * / 
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192 ©Override 

193 public Iterator<E> iterator () { 

194 return new Iterator <E>() { 

195 ListElement current = null ; 

196 ListElement next = head ; 

198 ©Override 

199 public boolean hasNextQ { 

200 return next != null ; 

201 } 

203 ©Override 

204 public E next () { 

205 if ( hasNextQ ) { 

206 current = next ; 

207 next = next . getTailwards ( ) ; 

208 return current . getElement () ; 

209 } else 

210 return null ; 

211 } 

213 /** 

214 * ©throws ConcurrentModificationException Thrown if the list 

215 * is modified during the execution of this method. 

216 * ©throws IllegalArgumentException Thrown if the list cannot 

217 * be modified; there are no elements to remove; or if 

218 * the iterator has not been moved from the initial 

219 * point . 

220 * / 

221 ©Override 

222 public void remove () { 

223 if ( sizeQ = ) 

224 throw new IllegalArgumentException ( "List is empty; there is 
nothing to remove . " ) ; 

225 if ( current = null ) 

226 throw new IllegalArgumentException ( "Iterator is before the first 
list item; call next () before removing an item." ); 

227 if ( ! isModifiable ) 

228 throw new IllegalArgumentException ( "List has been appended with 
an Unmodi f i ableLinkLi st and items cannot be removed from the 
list . " ) ; 

final long change = changes ; 

232 ListElementStore elements = removeElement ( current ); 

233 if ( elements != null ) { 

234 current = elements . getCurrent () ; 

235 next = elements . getNext () ; 

236 } else { 

237 current = null ; 
next = null ; 



238 
239 



} 



241 if ( change != changes ) 

242 throw new Concurrent ModificationExcept ion () ; 

243 incrementChange ( ) ; 

244 } 

245 } ; 

246 } 

248 /** 

249 * <p>An iterator to loop over the list from t ai 1 — to— head . </p> 

250 * <p>Overrides the iterator from the super — class to add 

251 * functionality to remove elements from the list.</p> 

252 * ©return Iterator <E> 
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253 * ©see mgt ay lor . d at as t r uc t ur es . Unmodif iableLinkList#i t e r at o r ( ) 

254 * Unmodif iableL inkList . i t e r a t o r ( ) 

255 * / 

256 ©Override 

257 public Iterator<E> r e ve r s e 1 1 er at or ( ) { 

258 return new Iterator <E>() { 

259 ListElement current = null ; 

260 ListElement prev = tail; 

262 ©Override 

263 public boolean hasNextQ { 

264 return prev != null ; 

265 } 

267 ©Override 

268 public E next () { 

269 if ( hasNextQ ) { 

270 current = prev ; 

271 prev = prev . getHeadwards ( ) ; 

272 return current . getElement () ; 

273 } else 

274 return null ; 

275 } 

277 /** 

278 * ©throws ConcurrentModificationException Thrown if the list 

279 * is modified during the execution of this method. 

280 * ©throws IllegalArgumentException Thrown if the list cannot 

281 * be modified; there are no elements to remove; or if 

282 * the iterator has not been moved from the initial 

283 * point . 

284 * / 

285 ©Override 

286 public void remove () { 

287 if ( size () = ) 

288 throw new IllegalArgumentException ( "List is empty; there is 
nothing to remove . " ) ; 

289 if ( current = null ) 

290 throw new Illegal ArgumentException ( "Iterator is before the first 
list item; call next () before removing an item." ); 

291 if ( ! isModifiable ) 

292 throw new Illegal ArgumentException ( "List is not modifiable." ); 
294 final long change = changes; 

296 ListElementStore elements = removeElement ( current ); 

297 if ( elements != null ) { 

298 current = elements . getNext () ; 

299 prev = elements . getCurrent () ; 

300 } else { 

301 current = null ; 

302 prev = null ; 

303 } 

305 if ( change != changes ) 

306 throw new Concurrent ModificationExcept ion () ; 

307 incrementChange ( ) ; 

308 } 

309 } ; 

310 } 

312 /** 

313 * An internal data structure used to store a valid state 

314 * for current & next elements when removing elements from 

315 * the list. 
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316 * ©author Martyn G Taylor 

317 */ 

3is protected class ListElementStore { 

319 /** 

320 * The current position in the list . When an element is 

321 * removed then the previous position is used. 

322 * / 

323 private final ListElement current ; 

324 /** 

* The next element in the list . 

*/ 

327 private final ListElement next ; 



325 
326 



329 / * * 

330 * Initialiser for the store 

331 * @param current 

332 * @param next 

333 * / 

334 public ListElementStore ( final ListElement current , final ListElement next 
) { 

335 this . current = current : 

336 this . next = next; 
} 

339 /*1 

340 * Gets the current element in the store 

341 * ©return ListElement 

312 

343 public ListElement getCurrent() { return current; } 

344 / * * 

345 * Gets the next element in the store . 

346 * Oreturn ListElement 

347 * / 

348 public ListElement getNextQ { return next; } 

349 
350 
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D.1.3 mgtaylor.datastructures.PermutableUnmodifableLinkList 

package mgtaylor . datastructures ; 

public class PermutableUnmodifableLinkList <E> extends UnmodifiableLinkList <E> { 

/* * 

* The permutable list that will be re— ordered when cycling through 
permutations . 

*/ 

private UnmodifiableLinkList <E> permutation = new 

Unmodif iableLinkList <E> () ; 

/** 

* The underlying list elements stored as an array. 

* <ul> 

* <li>The array is populated in the same order as the initial list ; the 

K<sup>th</sup> 

* element of the array maps to the K<sup>th </sup> element of the list.</li> 

* <li>This allows for constant time access to and modification of the list 
structure 

* using the array index. </li> 

* </ul> 

*/ 

private ListElement [ ] elements = null; 

/* * 

* An array storing the current position of each element in the elements 
array . 

* <ul> 

* <li>The index for this array is the initial order of the elements .</ li > 

* <li >Therefore the position of the element with the largest index will be 
stored 

* in the last index of this array; conversely the position of the smallest 
indexed 

* element will be in index of the array. </li> 

* </ul> 

*/ 

private int[] elementPositions = null; 

/* * 

* An array storing the current element index at a given position in the 
current 

* permutation . 

* <ul> 

* <li>The array is initialised with the position indexes increasing 
sequentially 

* as the elements are initially ordered s equent i ally . </ 1 i > 

* <li>After cycling through permutations , if the value of the array at index 
M is 

* N then the Mcsup>th</sup> element of the permutation list has been given 
an index 

* of N; this allows the algorithm to find the element index of a 
neighbouring element .</ 1 i > 

* 

*/ 

private int[] positionToElements = null; 

/* * 

* The total number of permutations; for an input list of N items there are 
N! permutations . 

* / 

private int totalPermutations = 0; 

/* * 
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* The index of the current permutation; ranging between and the total 
number of permutations . 

*/ 

private int currentPermutation = 0; 

// private int minChanges = Integer .MAX_VALUE; 

// private int maxChanges = 0; 

// private int totalChanges = 0; 

/* * 

* Gets the total number of permutations. 

* ©return int The total number of permutations. 

* / 

public int get Tot alPermut at ions ( ) { 

if ( elementPositions = null && sizeQ > ) 

generatePermutationData ( ) ; 
return totalPermutations ; 

} 

/* * 

* Returns the index of the current permutation . 

* ©return int The index of the current permutation . 

* / 

public int getCurrentPermutation ( ) { return currentPermutation; } 

/** 

* Gets the current permutation of the base list . 
* 

* ©return E[] The current permutation. 

*/ 

public UnmodifiableLinkList <E> getPermutation () { 
if ( elementPositions = null && sizeQ > ) 

generatePermutationData ( ) ; 
return permutation ; 

} 

/* * 

* Initialises the arrays of data used to iterate from one permutation to the 
next . 

* <p> 

* For a set with N elements and C constraints , this requires O(CN) time and 
0(N + C) 

* memory . 

* / 

©Suppress Warnings ( " unchecked " ) 

private void generatePermutationData ( ) { 

elements = new UnmodifiableLinkList . ListElement [ size () ]; 

positionToElements = new int [ sizeQ ]; 

elementPositions = new int [ sizeQ ] ; 

totalPermutations = 1; 

int i = 0; 

for ( ListElement element = permutation . head ; element != null; element = 
element . getTailwards ( ) ) { 

elements [ i ] = element ; 

positionToElements [ i ] = i ; 

elementPositions [ i ] = i; 

totalPermutations *= ++i ; 

} 

meetsConstraints = true; 

for ( PermutationConstraint constraint : constraints ) 

meetsConstraints &= co nst raint . test Const raint Aft er Generation () ; 
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in /** 

112 * Gets the next permutation of the cycle . 

113 * <p> 

114 * <b>Steinhaus— Johnson— Trotter Permutation Algorithm : </b> 

115 * <ul> 

116 * <li>Elements are initially ordered with an ascending index number from 
left -to-right . < / li > 

* <li>Elements are given a direction of travel , initially every element is 
travelling 

us * le f t war d s . </ li > 

119 * <li>Elements are mobile if , in their direction of travel , the neighbouring 

120 * element is not the end of the list or an element with a higher index 
number . < / 1 i > 

* <li>The element with the highest index is tested first , if it is mobile 
then it is 

* swapped with the neighbouring element in its current direction of 
travel;</li> 

* <li>If the element is not mobile then elements with successively lower 
indices are 

* tested until a mobile element is found; else the element with the lowest 
index is 

125 * swapped .</ 1 i > 

126 * <li>Once the element has been swapped then the direction of travel is 
reversed for all 

127 * elements with a higher index. </li> 

128 * </ul> 

129 * This algorithm follows a predictable pattern: 

130 * <ul> 

131 * <li>For a set with N elements , when cycling through permutations , the 
largest indexed 

* element will be moved on occasions when the current permutation index (C) 
i s not 

133 * exactly divisible by N (C mod N aEa 0).</li> 

134 * <li>This results in the pattern that: 

135 * <ul> 

136 * <li>The element with the largest index is moved from the right —to — 1 e f t 
of the list , 

* each of the (N — 1) swaps it takes to achieve this movement represents 
a possible 

138 * permutat ion ; </ 1 i > 

139 * <li>On the N<sup>th</sup> swap, when the element with the largest index 
is immobile 

* at the left end of the list , the next highest indexed mobile element is 
exchanged 

* with a neighbour and the direction of travel for the largest element is 
reversed;</li> 

* <li>On the (N + 1 )<sup>th </sup> to (2N -l)<sup>th</sup> swaps, the 
largest element 

143 * is moved back from 1 e ft —to — right ; and</li> 

144 * <li >On the 2N<sup>th</sup> swap, when the element with the largest 
index is immobile 

* at the right of the list , again the next highest indexed mobile element 
i s moved. < / 1 i > 

* <li>This process is repeated until all permutations have been cycled 
through . </ li > 

147 * </ul> 

148 * <li >Therefore for (N — 1) out of N steps the element with the largest 
index will be 

* moved and the direction of travel is moving left when (C mod 2N felt ; N) or 
right 

150 * ot her wise .</ 1 i > 

151 * <li>The element with the second largest index will move when (C mod N = 0) 
and 

* (C/N&nbsp ; mod&nbsp ; (N — &nbsp ; 1 )&nbsp ; aEa 0) and the direction of 
travel is left when 
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153 * (C/N mod 2(N - 1) &lt ; (N - 1)) or right ot her wise .</ 1 i > 

154 * <li>In general , the K<sup>th </sup> indexed element of an N element set 
will move when 

* C is exactly divisible by [aLR<sub>M=(k+l) . . . N</sub>M] and C is not 
exactly divisible by K; 

* the direction of travel is left if (C.K1/N! mod 2K &lt ; K) or right 
otherwise. < / 1 i > 

* <li>The element with index of 1 will only move when no other elements are 
mobile ; this 

* occurs when (for a set of N elements) the (N! — l)<sup>th</sup> 
permutation is reached 

* and the next permutation in the sequence is the 0<sup>th</sup> 
permutation , thus 

* resetting the permutation order back to match the original order. The 
l<sup>st </sup> 

161 * element always moves left .</li > 

162 * </ul> 

163 * 

164 * Speed of the algorithm (for a list with N elements): 

165 * <ul> 

166 * <li>There are N! permutations .</ li > 

167 * <li >[N! — (N — 1) !] of the permutations are reached by swapping the largest 

168 * (N<sup>th</sup>) element. This requires a single iteration of the 
loop.</li> 

* <li>Of the (N - 1)! remaining permutations, [(N— 1)! - (N - 2)!] are 
reached by 

* swapping the second largest element. This requires an iteration of the 
loop to 

* determine that the largest element is immobile and a second iteration to 
swap the 

172 * element .</ 1 i > 

173 * <li>The K<sup>th</sup> element is moved [K! — (K — 1) !] times during one 
entire cycle 

* through all possible permutations. Moving the K<sup>th</sup> element 
requires (N — K + 1) 

* iterations through the loop (checking that N<sup>th</sup> down to 
(K+l)<sup>th</sup> 

* elements are immobile) and one final iteration to swap the K<sup>th</sup> 
element . </ li > 

* <li>The l<sup>st </sup> element is moved once during the entire cycle , to 
go from the 

* [N! — 1] <sup>th</sup> permutation back to the 0<sup>th</sup> original 
permutation . To 

* move the l<sup>st </sup> element , the loop is iterated over [N — 1] times; 
this check 

* that the N<sup>th</sup> down to 2<sup>nd</sup> elements are immobile 
before the 

* l<sup>st </sup> element is swapped (once the previous elements are all 
immobile there 

* is no requirement to check for mobility of the l<sup>st </sup> element as 
there is only 

* one permutation where this occurs and the element is always mobile in this 
case ) . </ li > 

* <li>For an N element set , to cycle through all possible (N!) permutations 
requires a 

* total of [aLS<sub>K=2 . . .N</sub>K! ] iterations through the loop and [N!] 
swaps . </ li > 

186 * <ul> 

187 * <li>At N=3, there is a total of 6 permutations and the loop is iterated 
a total of 8 times giving an 

188 * average cost of 1.33 iterations per permutation .</ 1 i > 

189 * <li >At N=4, there are totals of 24 permutations and 32 iterations , 
again , giving an average cost of 

* 1.33 iterations per permut at ion . </ li > 
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206 



191 * <li>At N=5, there are totals of 120 permutations and 152 iterations , 
giving an average cost of 1.27 

192 * iterations per permutation .</ li > 

193 * <li >As N tends towards infinity the average cost tends towards 1 
iteration per permutation following the 

194 * approximation Average Cost = 1 + <sup>l</sup>/<sub>N</sub >.</ 1 i > 

195 * </ulx/li> 

196 * <li>The maximum cost for moving from one permutation to the next in the 
cycle is 0(N).</li> 

197 * </ul> 

198 * / 

199 public void nextPermutation ( ) { 

200 if ( size () <= 1 ) return; 

201 if ( elementPositions = null ) generatePermutationData ( ) ; 

203 int p = currentPermutation = ( currentPermutation + 1) % totalPermutations ; 

204 for ( int n = size () ; n > 1; n — ) { 
if ( p % n != ) { 

swapElement ( n — 1, (p%(2*n))<n); 

207 return ; 

208 } 

209 p /= n ; 

210 } 

211 swapElement ( , true ) ; 

212 } 

214 /** 

215 * For a given permutation index (P) of a set of elements (<l, ... N&gt ; ) , 
the 

216 * N<sup>th</sup> element will be in position (N — 1 — (P mod N) ) if (P mod 
2N felt ; N) 

217 * or in position (P mod N) otherwise. This leaves (N — 1) unassigned 
positions . 

218 * <p> 

219 * For the general K<sup>th</sup> element , that will be put in position 

220 * (K - 1 - (P.KI/N! modK)) if (P.K1/N! mod 2K < K) or in position (P.K1/N! 
mod K) 

221 * otherwise . If any elements with a higher index than K have an equal or 
lower 

222 * position then the position of the K<sup>th</sup> element is shifted right 
by one 

223 * for each of those elements . 

224 * <p> 

225 * For example, Permutation 23 of the set <1, 2, 3, 4, 5>: 

226 * <style> 

227 * table { border — collapse : collapse; width: 100%; } 

* table , tr , td , th { border : lpx solid black ; } 

* td , th { padding 2px; } 

230 * </style> 

231 * <table cellpadding = "2"> 

232 * <colgroup> 

233 * <col width = "5%" /> 

234 * <col width = "10%" /> 

235 * <col width = "10%" /> 

* <col width = "15%" /> 

* <col width = "10%" /> 

238 * <col width = "30%" /> 

239 * <col width = "20%" /> 

240 * </colgroup> 

241 * <tr> 

242 <th>K</th> 

243 * <th>P.K!/N!</th> 

244 * <th>P.K!/N! mod K</th> 

245 * <th>P.K!/N! mod 2K &lt ; K</th> 

246 * <th>I n i t i al <br />Position </th> 



228 
229 



236 
237 
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247 * <th>Position<br /> S hi f t s </th> 

248 * <th>Permutation</th> 

249 * </tr> 

250 * <tr> 

251 * <td>5</td> 

252 * <td>23</td> 

253 * <td>3</td> 

254 * <td>True</td> 

255 * <td>4 - 3 = l</td> 

256 * <td> </td> 

257 * <td>&lt ; null , 5, null, null, null&gt ;</td> 

258 * </tr> 

259 * <tr> 

260 * <td>4</td> 

261 * <td>23/5 = 4</td> 

262 * <td>0</td> 

263 * <td>False </td> 

264 * <td>0</td> 

265 * <td> </td> 

266 * <td><4, 5, null, null, nul l&gt ; </ td> 

267 * </tr> 

268 * <tr> 

269 <td>3</td> 

270 * <td>23/20 = K/td> 

271 * <td>l</td> 

272 * <td>True</td> 

273 * <td>2 - 1 = K/td> 

274 * <td>l a^S 2 (Due to 4<sup>th </sup> Element @ Position 0)<br />2 aES 3 (5 @ 
l)</td> 

275 * <td><4, 5, null, 3, n u ll&gt ; </ td> 

276 * </tr> 

277 * <tr> 

278 * <td>2</td> 

279 * <td>23/60 = 0</td> 

280 * <td>0</td> 

281 * <td>True</td> 

282 * <td>l - = K/td> 

283 * <td>l arJS 2 (4 @ 0)<br />2 a^S 3 (5 @ l)<br>3 a^S 4 (3 @ 3)</td> 

284 * <td><4, 5, null, 3, 2></td> 

285 * </tr> 

286 * <tr> 

287 * <td>l</td> 

288 * <td>23/120 = 0</td> 

289 * <td>0</td> 

290 * <td>True</td> 

291 * <td>0 - = 0</td> 

292 * <td>0 a^S 1 (4 @ 0)<br />1 aES 2 (5 @ l)</td> 

293 * <td><4, 5, 1, 3, 2></td> 

294 * </tr> 

295 * </table> 

296 * <P> 

297 * The minimum shifts occurs when generating the 0<sup>th</sup> permutation: 

298 * <table cellpadding = "2"> 

299 * <colgroup> 

300 * <col width = "5%" /> 

301 * <col width = "10%" /> 

302 * <col width = "10%" /> 

303 * <col width = "15%" /> 

304 * <col width = "10%" /> 

305 * <col width = "30%" /> 

306 * <col width = "20%" /> 

307 * </colgroup> 

308 * <tr> 

309 * <th>K</th> 
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310 * <th>P.K!/N!</th> 

311 * <th>P.K!/N! mod K</th> 

312 * <th>P.K!/N! mod 2K &lt ; K</th> 

313 * <th>I n i t i a 1 <br />Position </th> 

314 * <th>Position<br /> Shifts </th> 

315 * <th>Permutation</th> 

316 * </tr> 

317 * <tr> 

318 * <td>5</td> 

319 * <td>0</td> 

320 * <td>0</td> 

321 * <td>True</td> 

322 * <td>4 - = 4</td> 

323 * <td> </td> 

324 * <td>&lt ; null , null, null, null, 5></td> 

325 * </tr> 

326 * <tr> 

327 * <td>4</td> 

328 * <td>0/5 = 0</td> 

329 * <td>0</td> 

330 * <td>True</td> 

331 * <td>3 - = 3</td> 

332 * <td> </td> 

333 * <td>&lt ; null , null, null, 4, 5></td> 

334 * </tr> 

335 * <tr> 

336 <td>3</td> 

337 * <td>0/20 = 0</td> 

338 * <td>0</td> 

339 * <td>True</td> 

340 * <td>2 - = 0</td> 

341 * <td>&nbsp ; </ td> 

342 * <td>&lt ; null , null, 3, 4, 5></td> 

343 * </tr> 

344 * <tr> 

345 * <td>2</td> 

346 * <td>0/60 = 0</td> 

347 * <td>0</td> 

348 * <td>True</td> 

349 * <td>l - = K/td> 

350 * <td> </td> 

351 * <td>&lt ; null , 2, 3, 4, 5></td> 

352 * </tr> 

353 * <tr> 

354 * <td>l</td> 

355 * <td>0/120 = 0</td> 

356 * <td>0</td> 

357 * <td>True</td> 

358 * <td>0 - = 0</td> 

359 * <td>&nbsp ; </ td> 

360 * <td><l, 2, 3, 4, 5></td> 

361 * </tr> 

362 * </table> 

363 * <P> 

364 * The maximum shifts occurs when the permutation is generated such that the 
elements are in reverse order : 

365 * <table cellpadding = "2"> 

366 * <colgroup> 

367 * <col width = "5%" /> 

368 * <col width = "10%" /> 

369 * <col width = "10%" /> 

370 * <col width = "15%" /> 

371 * <col width = "10%" /> 

372 * <col width = "30%" /> 

373 * <col width = "20%" /> 
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374 * </colgroup> 

375 * <tr> 

376 * <th>K</th> 

377 * <th>P.K!/N!</th> 

378 * <th>P.K!/N! mod K</th> 

379 * <th>P.K!/N! mod 2K &lt ; K</th> 
3so * <th>I n i t i a 1 <br />Position </th> 

381 * <th>Position<br /> Shifts </th> 

382 * <th>Permutation </th> 

383 * </tr> 

384 * <tr> 

385 * <td>5</td> 

386 * <td>64</td> 

387 * <td>4</td> 

388 * <td>True</td> 

389 * <td>4 - 4 = 0</td> 

390 * <td>&nbsp ; </ td> 

391 * <td><5, null, null, null, n u ll&gt ; </td> 

392 * </tr> 

393 * <tr> 

394 * <td>4</td> 

395 * <td>64/5 = 12</td> 

396 * <td>0</td> 

397 * <td>False </td> 

398 * <td>0</td> 

399 * <td>0 ar?S 1 (5 @ 0)</td> 

400 * <td><5, 4, null, null, null&gt ; </td> 

401 * </tr> 

402 * <tr> 

403 * <td>3</td> 

404 * <td>64/20 = 3</td> 

405 * <td>0</td> 

406 * <td>False </td> 

407 * <td>0</td> 

408 * <td>0 aF,S 1 (5 @ 0)<br />1 ar?S 2 (4 @ l)</td> 

409 * <td><5, 4, 3, null, n u ll&gt ; </td> 

410 * </tr> 

411 * <tr> 

412 <td>2</td> 

413 * <td>64/60 = K/td> 

414 * <td>l</td> 

415 * <td>True</td> 

416 * <td>l - 1 = 0</td> 

417 * <td>0 aF,S 1 (5 @ 0)<br />1 ar?S 2 (4 & l)<br />2 a^S 3 (3 @ 2)</td> 

418 * <td><5, 4, 3, 2, null&gt ; </td> 

419 * </tr> 

420 * <tr> 

421 * <td>l</td> 

422 * <td>64/120 = 0</td> 

423 * <td>0</td> 

424 * <td>True</td> 

425 * <td>0 - = 0</td> 

426 * <td>0 aFvS 1 (5 @ 0)<br />1 ar?S 2 (4 © l)<br />2 ar?S 3 (3 @ 2)<br />3 arJS 4 
(2 @ 3)</td> 

427 * <td><5, 4, 3, 2, l></td> 

428 * </tr> 

429 * </table> 

430 * <ul> 

431 * <li>The maximum number of position assignments plus shifts is [A!/2NAs + 
Ai/2N].</li> 

432 * <li>The minimum number of position assignments plus shifts is N.</li> 

433 * <li>The average number of assignments per permutation, over a complete 
cycle 

434 * through N! permutations, is [Ai/4NAs + A3/4N] . < / 1 i > 
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435 * </ul> 



436 * 

437 * @param p The index of the permutation to jump to . 

438 * / 

439 public void jumpToPermutation ( final int p ) { 

440 if ( sizeQ <= 1 ) return; 

441 if ( elementPositions = null ) generatePermutationData ( ) ; 

443 currentPermutation = p % totalPermutations ; 

444 if ( currentPermutation < ) 

445 currentPermutation += totalPermutations ; 

447 int q = currentPermutation ; 

448 final AccessibleUnmodifiableLinkList <Integer > order = new 
AccessibleUnmodifiableLinkList <Integer >() ; 

449 // intk=0; 

450 ListElement listElement = tail; 

451 for ( int n = size () ; n >= 1; n — ) { 

452 int position = ( q % (2 * n) < n ) ?(n - (q % n) - 1) : (q % n) ; 

453 / / k++; 

454 Unmodif iableLinkList <Integer >. List Element phe = 
order . getHeadContainer () ; 

455 while ( phe != null &fe phe . getElement ( ) <= position ) { 

456 phe = phe . getTailwards ( ) ; 

457 positionH — h; 

458 // k++; 

459 } 

460 if ( phe = null ) 

461 order . addTail ( position ); 

462 else 

463 order . appendHeadwardsOf ( phe, position ); 

464 positionToElements[ position ] =n — 1; 

465 elementPositions] n — 1 ] = position; 

466 elements] position ] . setElement ( 1 ist Element . get Element ( ) ); 

467 listElement = list Element . get Headwards () ; 

468 q /= n ; 

469 } 

471 meetsConstraints = true; 

472 for ( PermutationConstraint constraint : constraints ) 

473 meetsConstraints &= co nst rai nt . test Const raint Aft er Generation ( ) 

474 // minChanges = Math.min( k, minChanges ) ; 

475 // maxChanges = Math.max( k, maxChanges ) ; 

476 // totalChanges += k; 

477 } 

479 /** 

480 * Gets the previous permutation of the cycle . 

481 * @see #nextPermutation () 

482 * / 

483 public void previousPermutation ( ) { 

484 if ( sizeQ <= 1 ) return; 

485 if ( elementPositions = null ) generatePermutationData ( ) ; 

487 int p = currentPermutation ; 

488 currentPermutation = currentPermutation = 0? t ot alPer mut at ions — 
1 : currentPermutation — 1; 

489 for ( int n = size () ; n > 1; n — ) { 
if ( p % n != ) { 

swapElement ( n — 1, (p % (2 * n) ) >= n ); 

492 return ; 

493 } 

494 p /= n ; 

} 



190 
191 



195 



496 swapElement ( 0, false 
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500 
501 
502 
503 
504 
505 
506 

507 
508 
509 

510 
511 
512 



/* * 

* Swaps the position of the element at the given index and the element 

* neighbouring it in the specified direction. 

* <p> 

* Constraint checking is O(C) where C is the number of constraints . 
* 

* @param mobileElement The index of the mobile element that is being swapped. 

* @param direction Whether the element at the given index is moving left 
( true ) 

* orright(false). 

* / 

protected void swapElement ( final int mobileElement , final boolean direction 
) { 

final int mobileElementPosition = elementPositions [ mobileElement ] ; 
final int swapElementPosition = mobileElementPosition + ( d ir e c t io n ? — 1 : 1 ) ; 
final int swapElement = positionToElements [ swapElementPosition ] ; 



514 elementPositions [ mobileElement ] = swapElementPosition; 

515 elementPositions] swapElement ] = mobileElementPosition; 

516 positionToElements [ mobileElementPosition ] = swapElement; 
5j7 positionToElements! swapElementPosition ] = mobileElement; 

519 final E temp = elements [ mobileElementPosition ] . getElement ( ) ; 

520 elements [ mobileElementPosition ] . setElement ( elements] 
swapElementPosition ]. getElement ( ) ); 
elements [ swapElementPosition ] . setElement ( temp ) ; 

5j; meetsConstraints = true; 

524 final E before ; 

525 final E after ; 

526 if ( direction ) { 

527 before = elements] swapElementPosition ]. getElement () ; 

528 after = elements] mobileElementPosition ]. getElement () ; 

529 } else { 

530 before = elements] mobileElementPosition ]. getElement () ; 

531 after = elements] swapElementPosition ]. getElement () ; 
. } 

533 for ( final PermutationConstraint constraint : constraints ) 

534 meetsConstraints &= constraint . testConstraint AfterSwap ( before, after ) 

535 handleSwap ( before , after ) ; 

536 } 



538 
539 
540 
511 
512 
543 



/* * 

* Method stub to allow sub— classes to handle swaps. 

* @param earlier The element swapped to an earlier position in the list . 

* @param later The element swapped to an later position in the list 

* / 

protected void handleSwap ( final E earlier , final E later ) {} 



545 ©Override 

546 public void addTail ( E element ) { 

547 if ( elements != null ) throw new IllegalArgumentException ( 
has been generated and elements cannot be added to the list . 

548 super . addTail ( element ); 

549 permutation . addTail ( element ); 

550 } 



' Permut at i on 



552 
553 
554 

555 
556 



©Override 

public void addHead( E element ) { 

if ( elements != null ) throw new IllegalArgumentException ( "Permutation 
has been generated and elements cannot be added to the list." ); 
super . addHead ( element ); 
permutation . addHead ( element ); 
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559 
560 
561 

562 
563 
564 

566 
567 
568 

569 
570 
571 

573 
574 
575 

577 
578 
579 
580 

582 
583 
584 
585 



597 
598 
599 
600 
601 

603 
604 



606 
607 
608 
609 
610 
611 
612 

614 
615 
616 



} 

©Override 

public void addAHTail( UnmodifiableLinkList <E> list ) { 

if ( elements != null ) throw new IllegalArgumentException ( "Permutation 
has been generated and elements cannot be added to the list . " ) ; 
super . addAHTail ( list ); 
permutation . addAHTail ( list ); 

} 

©Override 

public void addAHHead ( UnmodifiableLinkList <E> list ) { 

if ( elements != null ) throw new IllegalArgumentException ( "Permutation 
has been generated and elements cannot be added to the list." ); 
super . addAHHead ( list ); 
permutation . addAHHead ( list ); 

} 

* Constraints 

/* * 

* Flag to check whether the permutation meets the constraints . 

*/ 

protected boolean meetsConstraints = true; 

/* * 

* The constraints that the permutation must meet to be valid. 

*/ 

protected final UnmodifiableLinkList <PermutationConstraint > constraints = new 
UnmodifiableLinkList <PermutationConstraint >() ; 



587 


/* * 




588 


* Adds a constraint to the 


permutation . 


589 


* 




590 


* ©param before 




591 


* ©param after 




592 


*/ 




593 


public void addConstraint ( 


final E before , final E 


594 


constraints . add Tail ( new 


PermutationConstraint ( 


595 


} 





/** 

* Checks whether the permutation meets all the constraints . 

* ©return boolean Whether the permutation meets all constraints. 

* / 

public boolean isValidPermutation ( ) { return meetsConstraints; } 

/* * 

* Class storing a constraint on the permutation restricting the permutation 
to be 

* valid only when a given element appears in the permutation before another 
given 

* element . 

* ©author Martyn Taylor 

* / 

protected class PermutationConstraint { 
private final E elementBefore ; 
private final E elementAfter ; 
private boolean constraintMatched = true; 

/** 

* Adds a constraint to the permutation that one element should always be 

* earlier in the order than another element. 
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617 * @param before The element that should be earlier in the permutation. 

6is * @param after The element that should be later in the permutation . 

619 * / 

620 private PermutationConstraint ( final E before , final E after ) { 

621 if ( before = null ) throw new IllegalArgumentException ( 
"Constrained element cannot be null." ); 

if ( after = null ) throw new IllegalArgumentException ( "Constrained 
element cannot be null . " ) ; 

if ( before = after ) throw new Illegal ArgumentException ( 
"Constrained elements cannot be equal." ); 

624 elementBefore = before ; 

625 elementAfter = after ; 

626 } 



/** 

629 * Checks the elements being swapped to see if they match the constrained 

630 * elements and if so, whether they are in the correct order. 

631 * <ul> 

632 * <li>If the swapped elements match the constrained elements and they are 
in 

633 * the correct order after the swap then the constraint has been met;</li> 

634 * <li>If the swapped elements match the constrained elements and they are 
i n 

* the reverse order then the constraint is not matched and the 
permutation is 

636 * invalid; and</li> 

637 * <li>If one or more elements does not match the constrained elements then 

638 * the swap will not change the relative order of the constrained elements 

639 * and the validity of the permutation will be the same as the previous 

640 * permutation with regards to this c o ns t r aint . </ li > 

641 * </ul> 

642 * 

643 * @param swapFirst The swapped element that is now earlier in the 
permutation . 

* @param swapSecond The swapped element that is now later in the 
permutation . 

645 * ©return boolean Whether the constraint has been matched. 

*/ 

647 private boolean testConstraint AfterSwap ( final E swapFirst , final E 
swapSecond ) { 

648 if ( swapFirst = elementBefore &&; swapSecond = elementAfter ) 

649 constraintMatched = true ; 

650 else if ( swapFirst = elementAfter &fe swapSecond = elementBefore ) 

651 constraintMatched = false ; 

652 return constraintMatched ; 

653 } 

655 / * * 

656 * Iterates through the list of elements to find which if the constrained 

657 * elements is first in the list . If the element constrained to be earlier 
i n 

* the permutation is found first then the constraint is matched; 
otherwise , the 

* permutation is invalid . 

661 * ©return boolean Whether the constraint has been matched. 

662 * / 

663 private boolean test Const r aint Aft er Generation ( ) { 

664 for ( final E element : 
PermutableUnmodif ableLinkList . t his . get Permutation ( ) ) { 

665 if ( element = elementBefore ) { 

666 constraintMatched = true; 

667 return true ; 

668 } else if ( element = elementAfter ) { 

669 constraintMatched = false ; 
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670 
671 
072 
673 
674 
070 



return false 



} 

throw new Illegal ArgumentException ( "No constraint elements found." ) 



07 7 
678 
679 
680 



082 
683 
684 
685 

oso 

687 



/* 



// 
// 



092 
693 
09 1 



// 
// 

// 
P 

q 



public static void main( String [] args ) { 
for ( int n= 5; n <= 5; n++ ) { 

PermutableUnmodifableLinkList <Integer > p = new 

PermutableUnmodifableLinkList <Integer >() ; 

PermutableUnmodifableLinkList <Integer > q = new 

PermutableUnmodifableLinkList <Integer >() ; 

Integer [] pelements = new Integer) n j; 

Integer]] qelements = new Integer] n ]; 

for ( int m = 1; m <= n ; mf-+ ) { 

p.addTail( pelements] m — 1 ] = new Integer 
q.addTail( qelements] m — 1 ] = new Integer 

} 

p . addConstraint ( pelements] ] , pelements] 1 
p . addConstraint ( pelements] 1 ] , pelements] 2 
p . addConstraint ( pelements] 3 ] , pelements] 4 

q . addConstraint ( qelements] ] , qelements] 1 
q . addConstraint ( qelements] 1 ] , qelements] 2 
q . addConstraint ( qelements] 3 ] , qelements] 4 



m ) ) 
m ) ) 

) 



) 



09 7 
09S 
099 
700 
701 
702 



System . out . pr i nt 1 n ( p . getCurrentPermutation ( ) - 
getPermutation ( ) + '\t' + p . get CurrentPermut ation ( ) + 
getPermutation ( ) ); 

for ( int i = 1; i <= p . get Tot alPermut at ions ( ) 
p . nextPermutation ( ) ; 
q . jumpToPermutation ( i ) ; 
String ps = p . getPermutation ( ) 
String qs = q . getPermutation ( ) 
if ( ps . compareTo ( qs ) != | 
q . is ValidPermutation ( ) ) 

System . out . pr i nt 1 n ( p . get Current Permutation ( ) + ":\t" + ps + 
+ p . isValidPermutation () + ")\t" + q . getCurrentPermutation () 
":\t" + qs + " (" + q. isValidPermutation () + ")" ); 
System . out . println ( p . getCurrentPermutation ( ) + "/" + 



":\t" + 
':\t" + 

i++ ) { 



toString () ; 
toString () ; 
p . isValidPermutation ( ) ! = 



(" 



705 
706 



70 7 
70S 



709 
710 
711 
712 



// 
// 
P ■ 
P ■ 

// 
"\ 
(( 



p. getTotalPermutations () 
p . is ValidPermutation ( ) ) 
if ( qs . compareTo ( "<10, 



+ ":\t" + p . getPermutation ( ) + 



9, 8, 7, 6, 5, 4, 3, 2, 1>" ) 
get Current Permutation ( ) + "/" 
getPermutation ( ) + "\t" + 



■\t" - 
= ) 



System . out . pri nt In ( p 
getTotalPermutations () + ":\t" +p 
is ValidPermutation ( ) ); 
} 

System . out . pr i nt 1 n ( "Min: " + q.minChanges + "\tMax: " 
tTotal : " + q . totalChanges + "\tPerms: " + q . totalPermutations 
float ) q. totalChanges/q. totalPermutations) ) ; 
} 

} 

*/ 



q . maxChang 
r- "\t" + 
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D.1.4 mgtaylor.datastructures.UnmodifiableLinkList 

package mgtaylor . datastructures ; 

import java . util . ConcurrentModificationException ; 
import java. util . Iterator ; 

/** 

* <p>A doubly linked list structure that allows elements of the given 
enumerated type 

* to be added to, or retrieved from, the head or tail of the list and can 
iterate over 

* the entire list . The structure has no capability to: remove items from the 
list; edit 

* the order of the list ; insert items in the middle of the list ; or directly 

access 

* elements in the middle of the list.</p> 
* 

* <p>The structure can be accessed in Constant time to:</p> 

* <ul> 

* <li>Add an element to the head or tail;</li> 

* < 1 i >Concatenate this list with another of the same enumerated type;</li> 

* <li>Retrieve the head or tail element of the list ; and</li> 

* <li>Get the next element in the list from the i t e r a t o r . < / li > 

* </ul> 

* <p>The structure can be accessed in Linear tile to:</p> 

* <ul> 

* <li>Query the list to see if it contains an element; and</li> 

* <li>Get a string representation of the list.</li> 

* </ul> 

* ©author Martyn Taylor 

* 

* @param <E> 
*/ 

public class UnmodifiableLinkList <E> implements Iterable<E> { 

/ * * 

* Whether elements can be removed from the list . 

* / 

protected boolean isModifiable = false ; 

/* * 

* The wrapper for the head element of the list . 

* / 

protected ListElement head = null ; 

/* * 

* The wrapper for the tail element of the list . 

*/ 

protected ListElement tail = null; 

/* * 

* The number of elements in the list . 

* / 

protected int size = 0; 

/ * * 

* A reference variable to track changes to the data structure and 

* is used to highlight concurrent modification exceptions . 

*/ 

protected long changes = Long .MTN_ VALUE; 

/* * 

* Checks whether elements can be removed from the list . 

* ©return boolean 



APPENDIX D. JAVA SOURCE CODE 262 



67 



public boolean canRemoveElements ( ) { 
return isModifiable ; 

} 

/** 

* Checks whether there are no elements in the list . 
66 * ©return boolean 

*/ 

public boolean isEmptyQ { 
return size () = 0; 

} 

/* * 

* Add an element to the head of the list . 
* 

* Oparam element — The non- null element to be added. 

* ©throws ConcurrentModificationException Thrown if the list is modified 

* during the execution of this method. 

* ©throws IllegalArgumentException Thrown if the head of the list is 
connected 

* to another list and cannot be appended to. 

•/ 

si public void addHead( E element ) { 
82 if ( element = null ) 

throw new Illegal ArgumentException ( "Cannot add a null element." ); 
if ( head != null && head . getHeadwards ( ) != null ) 

throw new Illegal ArgumentException ( "Head element is connected to 
another list and cannot be appended to."); 
long change = changes ; 
if ( size = ) { 
88 head = tail = new ListElement( element ) ; 

so } else { 

ListElement le = new ListElement ( element ) ; 
le . setTailwards ( head ) ; 

92 head . setHeadwards ( le ); 

93 head = le ; 
} 

size ++; 

if ( change != changes ) 

97 throw new Concurrent ModificationExcept ion () ; 

98 incrementChange ( ) ; 
} 

101 /** 

102 * Add an element to the tail of the list . 

103 * 

104 * Oparam element — The non— null element to be added. 

105 * ©throws ConcurrentModificationException Thrown if the list is modified 
loe * during the execution of this method. 

107 * Othrows IllegalArgumentException Thrown if the tail of the list is 
connected 

108 * to another list and cannot be appended to. 

109 * / 

no public void addTail ( E element ) { 

in if ( element = null ) 

112 throw new IllegalArgumentException ( "Cannot add a null element." ); 

us if ( tail != null && t a i 1 . get Tail wards ( ) != null ) 

114 throw new Illegal ArgumentException ( "Tail element is connected to 
another list and cannot be appended to."); 

115 long change = changes ; 
lie if(size = ) { 

ii7 head = tail = new ListElement ( element ) ; 

us } else { 

no ListElement le = new ListElement ( element ) ; 
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120 le . setHeadwards ( tail ) 

121 tail . setTailwards ( le ) 

122 t a i 1 = le ; 

123 } 

124 size- 

125 if ( change != changes ) 

126 throw new ConcurrentModificationException ( ) ; 

127 incrementChange ( ) 

128 

130 /** 

131 * Returns the head element from the list or null if the list is empty. 

132 

133 * ©return felt ;Efcgt : 

134 

135 public E getHeadQ { 

136 if ( size = ) 

137 return null ; 

138 return head . getElement ( ) 

139 } 

141 /** 

142 * Returns the tail element from the list or null if the list is empty. 

143 

144 * ©return <E> 

145 

146 public E getTailQ { 

147 if ( size = ) 

148 return null ; 

149 return t a i 1 . get Element ( ) 

150 } 



152 



153 * Returns the element before the tail element from the list or null if 

154 * the list does not have at least two elements 

155 
156 
157 
158 
159 



public E getPenultimateTail ( ) { 
if ( size < 2 ) 

160 return null ; 

161 return t a i 1 . getHeadwards (). getElement () ; 

162 } 

164 /** 

165 * Returns the size of the list . 

166 * ©return int 

167 * / 

168 public int size () { 

169 return size ; 

J 7" } 

172 /** 

173 * Appends the contents of the given list to the head of this list . 

174 * 

175 * Oparam list — A non— null list of the same enumerated type. 

176 * ©throws IllegalArgumentException Thrown if the head of this list or the 
tail 

* of the given list are connected to another list and, therefore . 

cannot 

178 * be appended to . 

179 * / 
ISO 
1S1 



public void addAHHead ( UnmodifiableLinkList <E> list ) { 
if ( list = null ) 



182 throw new IllegalArgumentException ( "Cannot append a null list." ) 
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235 
236 



183 if ( head != null && head . getHeadwards ( ) != null ) 

184 throw new IllegalArgumentException ( "This list's head element is 
connected to another list and cannot be appended to."); 

185 if ( list, tail != null &&; list. tail. getTailwardsQ != null ) 

186 throw new Illegal ArgumentException ( "Given list's tail element is 
connected to another list and cannot be appended to."); 

187 if ( list, size () = ) 

188 return ; 

189 long change = changes ; 
loo long listChange = 1 i s t . changes ; 

192 isModifiable &= list . isModifiable ; 

194 if ( size = ) { 

195 head = list .head: 

196 tail = list, tail 

197 size = list, size 

198 } else { 

199 head . setHeadwards ( list . tail ) ; 

200 list . tail .setTailwards( head ) ; 

201 head = list .head; 

202 size += list . size ; 

203 } 

205 list, head = list, tail = null; 

206 list, size = 0; 

208 if ( change != changes | | listChange != list . changes ) 

209 throw new Concurrent ModificationExcept ion () ; 

210 incrementChange ( ) ; 

211 } 

213 /** 

214 * Appends the contents of the given list to the tail of this list . 

215 * 

216 * @param list — A non— null list of the same enumerated type. 

217 * ©throws IllegalArgumentException Thrown if the tail of this list or the 
head 

218 * of the given list are connected to another list and, therefore . 
cannot 

219 * be appended to . 

220 * / 

221 public void addAHTail( Unmodif iableL inkList <E> list ) { 

222 if ( list = null ) 

223 throw new IllegalArgumentException ( "Cannot append a null list." ); 

224 if ( tail != null && t a i 1 . get Tail wards ( ) != null ) 

225 throw new IllegalArgumentException ( "This list's tail element is 
connected to another list and cannot be appended to."); 

226 if ( list .head != null &&; list . head . getHeadwards ( ) != null ) 

227 throw new Illegal ArgumentException ( "Given list's head element is 
connected to another list and cannot be appended to."); 

228 if ( list, size () = ) 

229 return ; 

230 long change = changes ; 

231 long listChange = list .changes; 

233 isModifiable &= list . isModifiable ; 



if ( size = ) { 
head = 1 i s t . head : 

237 tail = list, tail 

238 size = list, size 

239 } else { 

240 tail . setTailwards( list . head ) ; 

241 list . head . setHeadwards ( tail ) ; 
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212 
243 
2-14 



tail = list, tail; 
size += list . size 



216 
217 

219 

250 
251 
252 



list, head = list, tail 
list, size = 0; 



null : 



if ( change != changes | | listChange != list . changes ) 

throw new Concurrent ModificationExcept ion () ; 
incrementChange ( ) ; 



251 
255 
256 
257 
258 
259 
260 
261 

263 
264 
265 
266 
207 
268 
209 
270 
271 
272 
273 
274 
275 
270 
277 

279 
280 
281 
282 
283 
284 
285 
280 
287 

289 
290 
291 
292 
293 
294 
295 
290 
297 
298 
299 
300 
301 
302 
303 
304 
305 
300 



/ * * 

* Checks whether a given element is contained within the list . 

* ©param element — The element to locate in the list . 

* ©return boolean 

* / 

public boolean contains ( final E element ) { 
return findElement ( element ) != null ; 

} 

/* * 

* Finds the internal list data structure containing the given element 

* within the list. 

* ©param element — The element to locate in the list . 

* ©return ListElement 

*/ 

protected ListElement findElement ( final E element ) { 
ListElement current = head; 
while ( current != null ) { 

if ( current . getElement ( ) = element ) 

return current ; 
current = current . getTailwards () ; 

} 

return null ; 

} 

/** 

* Returns a comma— space separated sequence representing the contents 

* of the list . The return value is bracketed by angle brackets (<>) . 

* ©see UnmodifiableLinkList#toString ( String ) toString( String ) 

* ©return String 

*/ 

public String toStringQ { 
return toString( ", " ); 

} 

/** 

* Returns a sequence representing the contents of the list . The return 

* value is bracketed by angle brackets (<>) and pairs of elements are 

* separated by the value of the function's separator argument. 

* ©param separator — A string defining the separator between list 

* elements . 

* ©return String 

* / 

public String toString( String separator ) { 
StringBuffer b = new StringBuffer () ; 
b . append ( ' < 1 ) ; 
boolean first = true; 
for ( E e: this ) { 
if ( first ) 

first = false; 
else 



b.append( separator ); 
b . append ( e ) ; 
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307 } 



b . append ( 1 > ' ) 



30S 

309 return b . t oString ( ) ; 
} 

313 /** 

314 * <p>Increments the counter recording the number of changes to the 

315 * data s t r uc t ur e . </p> 

316 * <p>Used as a simple (imperfect) method to detect concurrent 

317 * modification of a list.</p> 

318 * / 

319 protected synchronized void incrementChange ( ) { 

320 if ( changes = Long ,MAX_VALUE ) 

321 changes = Long .MTN_VALUE; 

322 else 

323 changes++; 

324 } 

326 /** 

327 * <p>The data structure used to store a single element of data within 

328 * the list </p> 

329 * ©author Martyn G. Taylor 

330 * / 

331 protected class ListElement { 

332 private E element ; 

333 private ListElement tailwards = null ; 

334 private ListElement headwards = null ; 

336 protected ListElement ( E element ) { 

337 this . element = element ; 

338 } 

340 protected void setElement ( E element ) { this . element = element ; } 

341 protected void setTailwards ( ListElement next ) { this . tailwards = next; } 

342 protected void setHeadwards ( ListElement prev ) { this . headwards = prev ; } 

344 protected E getElementQ { return element; } 

345 
346 

347 } 



352 
353 



protected ListElement getTailwards ( ) { return tailwards; } 
protected ListElement getHeadwards ( ) { return headwards; } 



349 /** 

350 * Returns an iterator to loop through the list from head— to — tail 

351 * ©return Iterator <E> 



©Override 

354 public Iterator<E> iterator () { 

355 return new Iterator <E>() { 

356 ListElement current = head; 

358 ©Override 

359 public boolean hasNextQ { 

360 return current != null ; 

361 } 

363 ©Override 

364 public E next () { 

365 if ( current = null ) 

366 return null ; 

367 E next = current . getElement () ; 

368 current = current . getTailwards () 

369 return next ; 

370 } 
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372 ©Override 

373 public void remove () { 

374 throw new IllegalArgumentException ( "Cannot remove from this list. 

); 

375 } 

376 } ; 

377 } 

379 /** 

3so * Returns an iterator to loop through the list from t a i 1 — to— head . 

3si * ©return Iterator<E> 

382 * / 

383 public Iterator<E> r e ve r s e 1 1 er at or ( ) { 

384 return new Iterator <E>() { 

385 ListElement current = tail; 

387 ©Override 

388 public boolean hasNextQ { 

389 return current != null ; 

390 } 

392 ©Override 

393 public E next () { 

394 if ( current = null ) 

395 return null ; 

396 E next = current . getElement () ; 

397 current = current . getHeadwards () ; 

398 return next ; 

399 } 

401 ©Override 

402 public void remove () { 

403 throw new IllegalArgumentException ( "Cannot remove from this list. 

); 

404 } 

405 } ; 

406 } 

407 } 
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D.2 Graph Files 



D.2.1 mgtaylor. graph. Block 



i package mgtaylor . graph ; 

import mgtaylor . datastructures . LinkList ; 

import mgtaylor . datastructures . UnmodifiableLinkList 



/ * > 



Jauthor Martyn Taylor 



*/ 

public class Block { 

public static final boolean INSIDE = true; 

public static final boolean OUTSIDE = ! INSIDE ; 

private LinkList <Segment> inside = new LinkList <Segment >() ; 

private LinkList <Segment> outside = new LinkList <Segment > () 

private UnmodifiableLinkList <Segment> embeddedlnside = new 
UnmodifiableLinkList <Segment >() ; 

private UnmodifiableLinkList <Segment> embeddedOutside = new 
UnmodifiableLinkList <Segment >() ; 

private final Segment parent ; 
private final Block previous ; 
private boolean flippable; 

private boolean inverted = false ; 

/* * 

* Creates a new block with the given segment on the inside . 

* (QSparam segment The non— null segment starting the block. 

public Block( final Segment segment ) { 

if ( segment = null ) throw new IllegalArgumentException ( "Segment 
cannot be null . " ) ; 

parent = segment . getParent () ; 

previous = parent . get Last ChildBlock () ; 

flippable = segment . i s F lip pable ( ) &fe ( parent . get P arent ( ) != null 
parent . get ChildSegments (). getHead ( ) != segment); 
inside . addTail ( segment ); 
embeddedlnside . addTail ( segment ) ; 

segment . getGraph (). addBlock ( this ); 

parent . addChildBlock ( this ); 

parent . setLastEmbeddedSegment ( segment ); 

if ( Graph .DEBUG_EMBED ) System . out . println ( "B: New Block " + 
segment . toString () ) ; 

} 

/** 

* Gets the parent segment for the block . 

* ©return Segment The non— null parent for the block . 

*/ 

public Segment getParent () { return parent; } 

/* * 

* Gets the previous block with the same parent . 

* ©return Block The previous block or null if there was no block that 

* was not already fully embedded when this block was added. 

*/ 
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public Block getPrevious ( ) { return previous; } 

/* * 

58 * Checks whether the block is flippable . If all the segments in the 

59 * block are flippable then the block is flippable. 

* ©return boolean Whether the block is flippable. 

*/ 

public boolean i s F 1 i p p ab le ( ) { return flippable; } 

/* * 

* Gets the list of segments on the inside of the block that are not 

66 * currently fully processed. 

67 * ©return {©link L inkList }& 1 1 ; { ©link Segment}&gt ; 

*/ 

public LinkList <Segment> get InsideSegment s ( ) { return inside; } 

/* * 

* Gets the list of segments on the outside of the block that are not 

* currently fully processed. 

* ©return {©link L inkL ist }& 1 1 ; { ©link Segment}&gt ; 

*/ 

public LinkList <Segment> getOutsideSegments ( ) { return outside; } 

78 / * * 

79 * Checks whether the inside of the block is empty. 

* ©return boolean True if it is empty, false otherwise. 

*/ 

public boolean isEmptylnside ( ) { return i n si de . isEmpty ( ) ; } 

/* * 

* Checks whether the outside of the block is empty. 

86 * ©return boolean True if it is empty, false otherwise. 



87 



101 
102 



public boolean isEmptyOutside ( ) { return out side . isEmpty () ; } 



90 / * * 

91 * Checks whether there are no segments (either embedded or fully embedded) 

* on the inside of the block. 

* ©return boolean True if it is empty, false otherwise. 

* / 

public boolean hasNoSegmentsInside ( ) { return embeddedlnside . isEmpty ( ) ; } 

/* * 

* Checks whether there are no segments (either embedded or fully embedded) 
99 * on the outside of the block. 

ioo * ©return boolean True if it is empty, false otherwise. 



public boolean hasNoSegmentsOutside ( ) { return embeddedOutside . isEmpty ( ) 

} 



104 /** 

105 * Gets the last segment embedded (but not fully embedded) on the 
loe * inside of the block. 

107 * ©return Segment The latest segment embedded on the inside of the 

los * block or null if the inside is empty. 

109 * / 

no public Segment ge t L as t Inside ( ) { return inside . getTail () ; } 

112 /** 

113 * Gets the last segment embedded (but not fully embedded) on the 

114 * outside of the block. 

115 * ©return Segment The latest segment embedded on the outside of the 

116 * block or null if the outside is empty. 

117 */ 

118 public Segment get Last Out side ( ) { return out side . get Tail () ; } 
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120 /** 

121 * Adds the given segment to the list of segments on the inside of the block. 

122 * @param segment A non— null segment that shares the same parent as the block. 

123 * / 

124 public void addSegmentlnside ( Segment segment) { 

125 if ( segment = null ) throw new Illegal ArgumentException ( 
"Segment cannot be null." ); 

126 if ( segment . getParent ( ) != getParentQ ) throw new 

Illegal ArgumentException ( "Block and segment have different parents." ); 

127 if ( ! segment . isFlippable ( ) ) 

128 flippable = false ; 

129 i n s i d e . addTail ( segment ); 

130 embeddedlnside . addTail ( segment ); 

131 parent . setLastEmbeddedSegment ( segment ); 

132 if ( Graph .DEBUG_EMBED ) System . out . println ( "B: Inside " + 
segment . toString () ) ; 

133 } 

135 /** 

136 * Adds the given segment to the list of segments on the inside of the block. 

137 * @param segment A non— null segment that shares the same parent as the block. 

138 * / 

139 public void addSegmentOutside ( Segment segment) { 

140 if ( segment = null ) throw new Illegal ArgumentException ( 
"Segment cannot be null." ); 

141 if ( segment . getParent ( ) != getParent () ) throw new 

Illegal ArgumentException ( "Block and segment have different parents." ); 

142 out side . addTail ( segment ) ; 

143 embeddedOutside . addTail ( segment ) ; 

144 parent . setLastEmbeddedSegment ( segment ); 

145 if ( Graph .DEBUG_EMBED ) System . out . println ( "B: Outside " + 
segment . toString () ) ; 

146 } 

148 /** 

149 * Checks if the last (non— fully embedded) segment on the inside 

150 * conflicts with the given segment. 

151 * @param segment The non— null segment to check for a conflict . 

152 * ©return boolean True is the segment conflicts , false otherwise. 

153 * / 

154 public boolean insideConflictsWith ( Segment segment) { 

155 if ( segment = null ) throw new IllegalArgumentException ( "Segment 
cannot be null . " ) ; 

156 return ! inside . isEmpty ( ) && ins ide . get T ai 1 (). co nf lie tsW it h ( segment ) ; 

157 } 

159 /** 

160 * Checks if the last (non— fully embedded) segment on the outside 

161 * conflicts with the given segment. 

162 * Oparam segment The non— null segment to check for a conflict . 

163 * ©return boolean True is the segment conflicts , false otherwise. 

164 * / 

165 public boolean outsideConflictsWith ( Segment segment) { 

166 if ( segment = null ) throw new IllegalArgumentException ( "Segment 
cannot be null . " ) ; 

167 return ! outside . isEmpty ( ) &&; out side . get Tail (). confli ct s Wit h ( segment ) ; 

168 } 

170 /** 

171 * Finds which side of the block has the given segment and appends the given 
list of segments 

172 * to the appropriate list . The segments are not added to the list of fully 
embedded segments 
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* as they are already embedded in another block which contains this 
information . 

* @param segment A non— null segment matching the last segment on one side of 
the block. 

* @param segments A non— null list of segments to be appended after the 
matched segment . 

176 * / 

177 public void appendSegmentsAfter ( Segment segment, LinkList <Segment> segments 
) { 

if ( segment = null ) throw new IllegalArgumentException ( "Segment 
argument cannot be null . " ) ; 

if ( segments = null ) throw new IllegalArgumentException ( "Segment list 
argument cannot be null . " ) ; 
j if ( i n side . get T ail ( ) = segment ) { 

isi inside . addAllTail ( segments ); 

182 } else if ( out side . get Tail ( ) = segment ) { 

183 outside . add AllTail ( segments ); 

184 } else 

j*.-, throw new IllegalArgumentException ( "Segment does not match the last 

segment on either side of the block. \n" + 

186 "Parent: " + segment . get P arent (). toS t ring ( ) + "\n" + 

187 "Inside: " + inside + "\n" + 

188 "Outside: " + outside + "\n" + 

189 "Segment: " + segment ); 

190 } 



192 
193 
194 
195 
196 
197 
198 

199 
200 
201 



/* * 

* Swaps the segments on the inside and outside of the block. 

* ©throws IllegalArgumentException If the block is not flippable . 

*/ 

public void flip () { 

if ( ! isFlippable () ) 

throw new IllegalArgumentException ( "Trying to flip a block that is not 
flippable . " ) ; 
final LinkList <Segment> temp = inside; 
inside = outside ; 
outside = temp; 



203 
204 
205 



final UnmodifiableLinkList <Segment> embeddedTemp = embeddedlnside : 
embeddedlnside = embeddedOutside ; 
embeddedOutside = embeddedTemp; 



if ( Graph .DEBUG_EMBED ) System . out . println (" Block flipped - I 
parent . to St ring ( ) + " In " + 

( inside . isEmpty ()?" null ": inside . get Tail (). toSt ring () ) + " Out 
(outside .isEmptyO?" null " : outside . getTail () . toString () ) ) ; 



210 
211 
212 
213 
214 
215 
216 
217 
218 
219 
220 
221 



222 
223 



/ * * 



Combines this 
©return Block 



block with the 



previous 



block . 



*/ 

public Block concatenate ( ) { 

previous . flippable &s= flippable ; 

previous . inside . addAllTail ( inside ); 

previous . outside . addAllTail ( outside ); 

previous . embeddedlnside . addAllTail ( embeddedlnside ) ; 

previous . embeddedOutside . addAllTail ( embeddedOutside 

parent . removeLastChildBlock () ; 



if ( Graph .DEBUG_EMBED ) 
parent . to St ring ( ) + " In 
(inside . isEmpty ( ) ? " null " : 
(outside .isEmpty()?" null ' 
return previous ; 



System .out. println ("Block concatenated 



inside . getTail () . toString () ) + ' 
: outside . getTail () . toString () ) ) 



Out 
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225 /** 

226 * Fully embeds segments that have a leaf vertex at or above the given index. 

227 * @param index 

228 * Ciireturn boolean — True if the block has been entirely fully embedded, 
otherwise false . 

*/ 

230 public boolean embedTo(int index) { 

231 while ( ! ins i d e . isEmpty ( ) && inside . getTail (). getLeafVertexDFSIndex ( ) >= 
index ) 

232 ins ide . removeTail ( ) ; 

233 while (! outside . isEmpty ( ) && outside . getTail (). getLeafVertexDFSIndex ( ) >= 
index ) 

234 outside . removeTail () ; 

235 if ( inside . isEmpty ( ) && out side . isEmpty () ) { 

236 return true ; 

237 } 

238 return false ; 



239 



250 



2T. i 



2T.7 



} 



241 public void assignBlockToSegments ( ) { 

242 for ( Segment segment : embeddedlnside ) { 

243 segment . setSide ( INSIDE ); 

244 segment . setEmbeddedBlock ( this ); 

245 } 

246 for ( Segment segment : embeddedOutside ) { 

247 segment . setSide ( OUTSIDE ); 

248 segment . setEmbeddedBlock ( this ); 

249 } 



} 

public boolean isRemovedQ { return embeddedlnside . isEmpty ( ) 

embeddedOutside . isEmpty () ; } 

public boolean isInvertedQ { return inverted; } 



255 public void invert () { inverted = 'inverted; } 



public String toStringQ { 

258 StringBuffer inBuffer = new StringBuffer () ; 

259 i nB uffer . append ("[") ; 

260 boolean first = true; 

261 for ( Segment segment : embeddedlnside ) { 

262 if ( first ) first = false; 

263 else inB uffer . append (" , "); 

264 inBuffer . append ( segment . toString ( ) ); 

265 } 

266 i nB uffer . append ("]") ; 

267 StringBuffer outBuffer = new StringBuffer () ; 

268 out B uffer . append ("[") ; 

269 first = true ; 

270 for ( Segment segment : embeddedOutside ) { 

271 if ( first ) first = false; 

272 else outBuffer . append (" , "); 

273 outBuffer . append ( segment . toString ( ) ); 
} 

275 out B uffer . append ("]") ; 

276 StringBuffer buffer = new S t r ing B uf f e r ( ) ; 

277 buffer . append (" { " ); 

278 // b uffer . append ( "Parent: " + parent . toString () 

279 buf fer . append ( "In: "); 

280 if ( inverted ) { 

281 buffer . append ( outBuffer ); 

282 buffer . append ( ", Out: " ); 

283 buffer . append ( inBuffer ); 

284 } else { 



APPENDIX D. JAVA SOURCE CODE 273 



285 buffer . append ( inBuffer ); 

286 buffer . append ( ", Out: " ); 

287 buffer . append ( outBuffer ); 

288 } 

289 buffer . append ( " }"); 
return buffer . toString () ; 



290 
291 
2 92 



D.2.2 mgtaylor. graph. Edge 

package mgtaylor . graph ; 

import j ava . u t i 1 . Array List ; 
import java. util . Collection ; 

public class Edge implements GraphObject { 

* The graph the edge belongs to . 

* / 

private final Graph graph; 

/* * 

* The vertex designated as the "from" end of the edge. 

*/ 

private final Vertex from; 

18 / * * 

19 * The vertex designated as the "to" end of the edge. 

*/ 

private final Vertex to ; 

/* * 

* The index of the edge within the graph's array of edges. 

*/ 

private final int index; 

/** 

* The index of the edge within the "from" vertex's array of connected edges 

30 * / 

31 private final int fromlndex ; 

/** 

34 * The index of the edge within the "to" vertex's array of connected edges. 



35 



private final int tolndex ; 



38 / * * 

39 * Creates an edge connecting the "from" and "to" vertices. 

* Oparam graph — A non— null graph. 

* Oparam from — A non— null vertex belonging to the given graph. 

* @param to — A different non— null vertex belonging to the given graph. 

* Oparam index — The index of the edge within the graph's array of edges. 

*/ 

public Edge( final Graph graph, Vertex from, Vertex to, int index) { 
if ( graph = null ) throw new Illegal ArgumentException ( 

" taylor . graph . Edge ( Graph, Vertex, Vertex, int ) - Graph cannot be null." 

); 

if ( from = null ) throw new IllegalArgumentException ( 

" taylor . graph . Edge ( Graph, Vertex, Vertex, int ) - \"From\" vertex cannot 
be null . " ) ; 



18 

19 

50 

51 

52 
53 
54 
55 
56 
57 
58 

60 
61 
02 
63 
64 

66 
67 
68 
69 
70 

72 
73 
71 
75 
76 

78 
79 
80 
81 
82 

84 
85 
86 
87 
88 
89 

91 
92 

93 
94 
95 
96 
97 
98 
99 
100 
101 
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if ( to = null ) throw new Illegal ArgumentException ( 

" t ay 1 or . graph . Edge ( Graph, Vertex, Vertex, int ) - \"To\" vertex cannot be 

null . " ) ; 

if ( from . getGraph ( ) != graph ) throw new IllegalArgumentException ( 

" t ay 1 or . graph . Edge ( Graph, Vertex, Vertex, int ) - \"From\" vertex belongs 

to a different graph." ); 

if ( to . getGraph ( ) != graph ) throw new IllegalArgumentException ( 

" t ay 1 or . graph . Edge ( Graph, Vertex, Vertex, int ) - \"To\" vertex belongs 

to a different graph." ); 

if ( from = to ) throw new Illegal ArgumentException ( 

" t ay 1 or . graph . Edge ( Graph, Vertex, Vertex, int ) - \"From\" and \"to\" 

vertices cannot be the same vertex." ); 

this. graph = graph; 

this, from = from; 

this .to = to ; 

this . index = index; 

fromlndex = from . connectTo ( this ); 
tolndex = to . connectTo ( this ); 

} 

/ * * 

* Returns the graph that the edge belongs to . 

* ©return Graph 

* / 

public Graph getGraph () { return graph; } 

/* * 

* Returns the vertex designated as the "From" end. 

* ©return Vertex 

*/ 

public Vertex getFromQ { return from; } 

/ * * 

* Returns the vertex designated as the "To" end. 

* ©return Vertex 

*/ 

public Vertex getToQ { return to; } 

/* * 

* Returns the index of the edge within the Graph's array of edges. 

* ©return int 

* / 

public int getlndexQ { return index; } 

/ * * 

* Checks whether the given vertex is either of the "From" or "To" vertices. 

* ©param vertex — The vertex to check. 

* ©return boolean 

*/ 

public boolean contains ( Vertex vertex ) { return vertex = from | 

vertex = to ; } 

/ * * 

* Returns the opposite end of the edge from the given vertex or null if the 
vertex 

* is not contained in the edge. 

* ©param vertex 

* ©return Vertex 

*/ 

public Vertex getOtherEndFrom ( Vertex vertex ) { 
if ( vertex = from ) return to; 
if ( vertex = to ) return from; 

return null ; 

} 



APPENDIX D. JAVA SOURCE CODE 275 



103 * 

104 * Returns the index to the edge within the given vertex 's array of connected 
edges 

105 * ©param vertex — A vertex terminating the edge, 
loe * ©return int 

107 

ios public int get Orderlndex ( Vertex vertex ) { 
109 if ( vertex = from ) 

no return fromlndex ; 

in else if ( vertex = to ) 

112 return tolndex; 

113 else 

114 throw new Illegal ArgumentException ( " mt ay lor . graph . Edge . get Or der Index ( 
vertex ): Invalid Vertex." ) 

} 



us 

119 



public String toStringQ { 
if ( isDFSVisited () ) 
120 return "(" + getDFSFrom ( ) . t oS t r ing ( ) + " , " + getDFSTo ( ) . t o S t r ing ( ) 

" ) " ; 

return "(" + from . to S t ring ( ) + ", " + to . t oS t r ing ( ) + ")"; 

} 



121 
122 



124 ©Override 

125 public Collection <Edge> getConnectedEdges ( ) { 

126 // TODO Remove 

127 Collection <Edge> fe = from . getConnectedEdges () ; 

128 Collection <Edge> te = to . getConnectedEdges () ; 

129 Array List <Edge> ce = new ArrayList <Edge>( f e . size () + te . size () ) ; 

130 ce . addAll ( fe ) ; 

131 ce . addAll ( te ) ; 

132 return ce ; 

133 } 

135 ©Override 

136 public boolean isConnectedTo ( Edge edge) { 

137 return t his . getFrom (). isConnectedTo ( edge ) || t his . getTo (). isConnectedTo ( 
edge ) ; 

} 

i4i * DFS 

143 /** 

144 * Tag to mark the edge as a stem edge in the DFS tree . 

145 * / 

146 public static final boolean DFS STEM = true; 

148 /** 

149 * Tag to mark the edge as a frond edge in the DFS tree . 

150 * / 

151 public static final boolean DFS_FROND = !DFS_STEM; 

153 /** 

154 * Flag to show if the edge has been visited by the DFS algorithm. 

155 * / 

156 private boolean dfsVisited = false ; 

158 /** 

159 * Flag to show if the edge is a Stem or Frond within the DFS tree . 

160 * / 

161 private boolean dfsType = DFS_FROND; 

/* * 
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164 * Sets the flag for whether the edge has been visited by the DFS 

165 * algorithm . 

166 * / 

167 public void setDFS Visited ( boolean visit ) { dfsVisited = visit ; } 

169 /** 

170 * Checks whether the edge has been visited by the DFS algorithm. 

171 * ©return boolean 

* / 



172 
173 



199 
200 



public boolean isDFS Visited ( ) { return dfsVisited; } 



175 /** 

176 * Checks whether the edge is a Stem edge within the DFS tree . 

177 * ©return boolean 

178 * / 

179 public boolean isDFSStemQ { return isDF S Visit ed ( ) &fe dfsType = 
DFS_STEM; } 

181 /** 

182 * Checks whether the edge is a Frond edge within the DFS tree . 

183 * ©return boolean 

184 * / 

185 public boolean isDFSFrondQ { return isDFS Visited ( ) &&: dfsType 
= DFS_FROND; } 

187 /** 

188 * Sets the type (Stem or Frond) for the edge within the DFS tree. 

189 * / 

190 public void setDFSType( boolean type ) { dfsType = type; } 

192 /** 

193 * Returns the vertex the edge originates from within the DFS tree. 

194 * If the edge is a Stem edge this will be the vertex with the lower 

195 * DFS index; for a Frond edge this will be the vertex with the 

196 * higher DFS index . 

197 * ©return Vertex 

198 * / 

public Vertex getDFSFromQ { 
if ( isDFSStemQ ) 

201 return from . getDFSIndex ( ) < to . getDFSIndex ( ) ? from : t o ; 

202 else if ( isDFSFrondQ ) 

203 return from . getDFSIndex ( ) < to . getDFSIndex Q? to : from ; 

204 else 

205 return null ; 

206 } 

208 /** 

209 * Returns the vertex the edge goes to in the DFS tree . 

210 * If the edge is a Stem edge this will be the vertex with the higher 

211 * DFS index; for a Frond edge this will be the vertex with the 

212 * lower DFS index . 

213 * ©return Vertex 

214 * / 

215 public Vertex getDFSToQ { 

216 if ( isDFSStemQ ) 

217 return from . getDFSIndex ( ) < to . getDFSIndex Q? to : from ; 

218 else if ( isDFSFrondQ ) 

219 return from . getDFSIndex ( ) < to . getDFSIndex Q? from : to ; 

220 else 

221 return null ; 

222 } 

225 * Order 
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227 /** 

228 * The next clockwise edge from this edge connected to the from vertex. 

229 * / 

230 private Edge order_From_Clockwise = this ; 

232 /** 

233 * The next anti — clockwise edge from this edge connected to the from vertex. 

234 * / 

235 private Edge order_From_ Anticlockwise = this ; 

237 /** 

238 * The next clockwise edge from this edge connected to the to vertex. 

239 * / 

240 private Edge order_To_Clockwise = this ; 

242 /** 

243 * The next anti — clockwise edge from this edge connected to the to vertex. 

244 * / 

245 private Edge order_To_ Anticlockwise = this ; 

247 /** 

248 * Resets the edge to be unordered . 

249 * / 

250 public void resetOrder () { 

251 order_From_ Clockwise = this ; 

252 order_From_ Anticlockwise = this ; 

253 order_To_Clockwise = this ; 

254 order_To_ Anticlockwise = this ; 

255 } 

257 /** 

258 * Checks whether the edge has been ordered about the given vertex . 

259 * @param center 

260 * ©return boolean 

261 * / 

262 public boolean isOrdered About ( final Vertex center ) { 

263 if ( center = from ) 

264 return from, size () = 1 || ( order_From_ Clockwise != this &fe 
order_From_ Anticlockwise != this ) ; 

265 // return ( order_From_Clockwise != this &&; order_From_ Anticlockwise ! = 
this ) ; 

266 else if ( center = to ) 

267 return to. size () = 1 || ( order_To_Clockwise != this &fe 
order_To_ Anticlockwise != this ) ; 

268 // return ( order _ To_ Clockwise != this &&: order_To_ Anticlockwise != this ): 

269 else 

270 throw new Illegal ArgumentException ( "Center vertex is not connected to 
the edge - " + this + " , " + center ) ; 

271 } 

273 /** 

274 * Gets the edge ordered clockwise from the current edge about the given 

275 * central vertex. 

276 * (Sparam center 

277 * ©return Edge 

278 * / 

279 public Edge getOrderClockwiseFrom ( final Vertex center ) { 

280 if ( center = from ) 

281 return order_From_Clockwise ; 

282 else if ( center = to ) 

283 return order_To_Clockwise ; 

284 else 

285 throw new Illegal ArgumentException ( "Center vertex is not connected to 
the edge - " + this + " , " + center ) ; 

286 } 
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288 /** 

289 * Gets the edge ordered ant i — cloc kwise from the current edge about the given 

290 * central vertex. 

291 * Oparam center 

292 * ©return Edge 

293 * / 

294 public Edge getOrder AntiClockwiseFrom ( final Vertex center ) { 

295 if ( center = from ) 

296 return order From AntiClockwise ; 

297 else if ( center = to ) 

298 return order_To_ Anticlockwise ; 

299 else 

300 throw new Illegal ArgumentException ( 
" taylor . graph . Edge . get Or der Ant i Clo ckwi seFrom ( vertex ): Center vertex 
is not connected to the edge - " + this + " , " + center ) ; 

} 

303 /** 

304 * Sets the edge ordered clockwise from the current edge about the given 

305 * central vertex. 

306 * @param center The vertex at the centre of the edges being ordered . 

307 * @param clockwise The edge being ordered clockwise of this edge. 

308 * / 

309 private void setOrderClockwiseFrom ( final Vertex center , final Edge clockwise 
) { 

310 if ( center = from ) 

311 order_From_Clockwise = clockwise ; 

312 else if ( center = to ) 

313 order_To_Clockwise = clockwise ; 

314 else 

315 throw new Illegal ArgumentException ( "Center vertex is not connected to 
the edge - " + this + " , " + center ) ; 

} 



318 / H 

319 * Sets the edge ordered ant i —clock wise from the current edge about the given 

320 * central vertex . 

321 * @param center The vertex at the centre of the edges being ordered 

322 * @param anticlockwise The edge being ordered anti —clockwise of this edge. 

323 * / 

324 private void setOrderAntiClockwiseFrom ( final Vertex center , final Edge 
anticlockwise ) { 

325 if ( center = from ) 

326 order_From_ Anticlockwise = anticlockwise ; 

327 else if ( center = to ) 

328 order To Anticlockwise = anticlockwise : 

329 else 

330 throw new Illegal ArgumentException ( "Center vertex is not connected to 
the edge - " + this + " , " + center ) ; 

} 

333 / H 

334 * Orders the given edge clockwise from the current edge about the 

335 * given central vertex 

336 * Oparam center 

337 * (Sparam clockwise 

338 

339 public void setOrderClockwise ( final Vertex center , final Edge clockwise ) { 

340 Edge cw = getOrderClockwiseFrom ( center ) 

341 cw . setOrder AntiClockwiseFrom ( center, clockwise ); 

342 clockwise . setOrderClockwiseFrom ( center, cw ) 

343 clockwise . setOrderAntiClockwiseFrom ( center, this ) 

344 this . setOrderClockwiseFrom ( center , clockwise ) 

345 } 
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/* * 

* Orders the given edge anti — cloc kwise from the current edge about the 

* given central vertex. 

* @param center 

* @param clockwise 

*/ 

public void setOrder Anticlockwise ( final Vertex center , final Edge 
anticlockwise ) { 

Edge acw = getOrder AntiClockwiseFrom ( center ); 

acw . setOrderClockwiseFrom ( center, anticlockwise ); 

anticlockwise . setOrder AntiClockwiseFrom ( center, acw ); 

anticlockwise . setOrderClockwiseFrom ( center, this ); 

this . setOrder AntiClockwiseFrom ( center, anticlockwise ); 

} 

* Planarity Conflict 

/* * 



private boolean conflict = false ; 

/* * 

* Flags the edge as part of a planarity conflict . 

*/ 

public void setConflictEdge ( ) { conflict = true; } 

/** 

* Checks whether the edge is part of a planarity conflict . 

* @return True if the edge is part of a planarity conflict , false otherwise 

* / 

public boolean hasPlanarityConflict ( ) { return conflict; } 



D.2.3 mgtaylor. graph. Graph 



i package mgtaylor . graph ; 

mport java. util .Arrays; 

mport java. util . Iterator ; 

mport java . util . ArrayList ; 

mport java. util .regex. Pattern; 

mport java . util . regex . Matcher ; 

mport java . io . PrintStream ; 

mport mgtaylor . datastructures . LinkList ; 
import mgtaylor . datastructures . UnmodifiableLinkList ; 

/** 

* Graph is a data structure that contains a list of unique vertices and ec 

* connecting pairs of vertices. 



* ©author Martyn G Taylor 

./ 

public class Graph { 

public static final boolean DEBUG = false ; 

public static final boolean DEBUG DFS = DEBUG & false; 

public static final boolean DEBUG_EMBED = DEBUG & true ; 

public static final boolean DEBUG ORDER = DEBUG & true ; 
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private 
private 

" ) , ( " + 

/ / private 



static final String VERTEX_RBGEX 
static final String EDGE_RBGEX 
VERTEX_REGEX + ")\\)\\s*"; 

static final Pattern EDGE_PATTERN 

VERTEX_REGEX + ")\\)\\s*' 



'\\s*[a-zA- 
'\\s*\\((" 



Z0 -9] +\\s* " ; 
+ VERTEX REGEX 



Pattern . compile ( "\\s*\\((' 
Pat tern. CASE INSENSITIVE + 



= Pattern . compile ( EDGE_REGEX, 

); 



VERIEX_REGEX + " ) , ( 1 
Pattern .MULTILINE ) ; 

private static final Pattern EIX3E_PATTERN 
Pattern . CASE_INSENSITIVE + Pattern .MULTILINE 
private static final String VERTICES_REGEX 
"\\s*nodes\\s*\\{([~\\}]+) \\}\\s*" ; 
private static final String EDGES REGEX = 
"\\s* edges \\s*\\{([~\\}]+) \\}\\s*" ; 

public static final Pattern VERTICES_PATTERN = Pattern . compile ( 
VERTICES_REGEX, Pattern . MULTILINE + Pattern . CASE_INSENSITIVE ); 
public static final Pattern EIX3ES_PATTERN = Pattern . compile ( EDGES_REGEX, 
Pattern .MULTILINE + Pattern . CASE_INSENSITIVE ); 

// public static final Pattern GRAPH_PATTERN = Pattern . compile ( 
"\\s*nodes\\s*\\{((" + VERTEX_REGEX + ",)*" + VERTEX_REGEX + 
")\\}\\s*edges\\s*\\{((" + EDGE_REGEX + ",)*" + EDGE_REGEX + ")\\}\\s*", 
Pattern .MULTILINE + Pattern . CASE_INSENSITIVE ); 

public static final Pattern GRAPH_PATTERN = Pattern . compile ( 
VERTICES_REGEX + EDGES_REGEX, Pattern . MULTILINE + Pattern . CASE_INSENSITIVE ) 



protected final Array List <Vertex> 
protected final ArrayList <Edge> 
private final LinkList <GraphListener> 
LinkList <GraphListener >() ; 
private String 



vertices ; 
edges ; 

graphListeners = new 



identifier 



public Graph( int numberOfVertices , int numberOfEdges ) { 
if ( numberOfVertices < ) 

throw new IllegalArgumentException ( "Cannot have negative number of 

vertices - " + numberOfVertices ) ; 
if ( numberOfEdges < ) 

throw new IllegalArgumentException ( "Cannot have negative number of 

edges - " + numberOfEdges ) ; 



vertices = new ArrayList <Vertex >( numberOfVertices ) 
edges = new Array List <Edge >( numberOfEdges ); 



public Graph( String input) { 

final Matcher m = GRAPH_PATTERN. matcher ( input ) ; 
if ( !m. matches () ) 

throw new IllegalArgumentException ( "Invalid Graph\n" + input ) ; 

final LinkList <GraphObject> graphObjects = new LinkList <GraphObject >() ; 

final String[] ids =m. group(l). split (","); 

final j ava . u t i 1 . HashMap<St r ing , Integer> idMap = new 

j ava . u t i 1 . HashMap<String , Integer>( ids. length ); 

int index = 0; 

for ( final String vertexID : ids ) { 

if ( idMap . containsKey ( vertexID . trim ( ) ) ) 

throw new IllegalArgumentException ( "Duplicate Vertex ID\n" + input 

); 

idMap .put( vertexID. trim ( ) , index^+ ) ; 

} 

final int [] vertexSizes = new int [ index ] ; 
int e = 0; 

vertices = new ArrayList <Vertex >( index ); 

final String [] edgeStrings = m. group (2) . sp 1 it ( " (? <=\\) ) \\ s* , \\ s * (?=\\ ( ) " ) 
for ( final String edge: edgeStrings ) { 
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final Matcher em = EDGE_PATIERN. matcher ( edge ); 
if ( em. matches () ) { 

final String fromID = em. group (1) . trim() ; 

final Integer fromlndex = idMap.get( fromID ); 
if ( fromlndex = null ) 

throw new IllegalArgumentException ( "Unknown Edge - From Vertex 
ID - C " + em . group ( 1) . trim () + ", " + em .group(2).trim() + ")\n" 
+ input ) ; 

final String toID = em . group (2) .trimQ ; 
final Integer tolndex = idMap.get( toID ); 

82 if ( tolndex = null ) 

83 throw new IllegalArgumentException ( "Unknown Edge - To Vertex ID 
- ( " + em . group (1). trimQ + ", " + em . group(2). trimQ + ")\n" + 
input ) ; 

if ( fromlndex = tolndex ) 

throw new Illegal ArgumentException ( "Invalid Self - Ref er ent ial 
Edge - ( " + em . group(l). trimQ + ", " + em . group(2). trimQ + 
" ) \n" + input ) ; 

vertexSizes [ fromlndex ] + + ; 
vertexSizes [ tolndex ] + + ; 
so e++; 
91 } else 

throw new IllegalArgumentException ( "Cannot match input to edge 
pattern: " + edge ) ; 

} 

for ( final String id : ids ) { 

final int i = idMap.get( id. trimQ ); 

97 graphObjects. addHead ( createVertex ( i, id. trimQ, vertexSizes[i] ) ); 

98 } 

100 edges = new ArrayList <Edge>( e ) ; 

101 for ( final String edge: edgeStrings ) { 

102 final Matcher em = EDGE_PATTERN . matcher ( edge ); 

103 if ( em. matches () ) 

104 createEdge( vertices. get( idMap . get ( em .group(l). trimQ ) ), 

105 vertices . get ( idMap. get ( em . group ( 2 ) . t rim ( ) ) ) ); 

106 } 

107 } 

109 /** 

no * Sets the identifier string for the graph, 

in * ©param string The identifier for the graph. 

112 */ 

jj; public void s e 1 1 d e n t i f i e r ( S t r ing string) { identifier = (string 

null " : string ) ; } 



115 /** 

116 * Gets the graph's identifier. 

117 * ©return String The graph's identifier. 

*/ 

public String g e 1 1 d e n t i f i e r ( ) { return identifier; } 



us 

119 



121 /** 

122 * Gets the vertices of the graph. 

123 * ©return {©link ArrayList}&lt ; { ©link Vertex}&gt ; An ArrayList of Vertices 

124 * / 

125 public ArrayList <Vertex> get Vert ices ( ) { return vertices; } 

127 /** 

128 * Gets the number of vertices in the graph. 

129 * ©return int The number of vertices . 
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130 
131 



public int vertexSizeQ { return ve r t i c e s . s i z e ( ) ; } 



133 /** 

134 * Checks to see if the given vertex is in this graph. 

135 * ©param vertex The non— null vertex to check. 

136 * ©return boolean True if the graph contains the vertex, false otherwise. 

137 * / 

138 public boolean contains ( final Vertex vertex ) { 

139 if ( vertex = null ) throw new IllegalArgumentException ( "Vertex 
argument cannot be null . " ) ; 

140 return vertex . getGraph ( ) = this && ve r t i c e s . get ( vertex . getlndex ( ) ) = 
vertex ; 

141 } 

143 /** 

144 * Gets the edges of the graph. 

145 * ©return {©link Arr ay L ist }& 1 1 ; { ©link Edge}&gt ; An ArrayList of Edges. 

146 * / 

147 public ArrayList <Edge> getEdges() { return edges; } 

149 /** 

150 * Gets the number of edges in the graph . 

151 * ©return int The number of edges . 

152 * / 

153 public int edgeSize () { return edges . size () ; } 

155 /** 

156 * Checks to see if the given edge is in this graph. 

157 * ©param vertex The non— null edge to check. 

158 * ©return boolean True if the graph contains the edge, false otherwise. 

159 * / 

160 public boolean contains ( final Edge edge ) { 

161 if ( edge = null ) throw new Illegal ArgumentException ( "Edge argument 
cannot be null . " ) ; 

162 return edge . getGraph ( ) = this && edges . get ( edge . getlndex ( ) ) = edge; 

163 } 

165 public void addGraphListener ( final GraphListener listener) { 
graphListeners . addHead (listener); } 

166 public void removeGraphListener ( final GraphListener listener) { 
graphListeners . remove (listener); } 

167 public void fireGraphUpdate ( final GraphEvent event) { 

168 for (GraphListener listener: graphListeners) 

169 listener . graphChanged ( event ) ; 

170 } 

172 /** 

173 * Creates a new vertex with the given label and capacity to connect edges 

174 * ©param label The label string for the vertex. 

175 * ©return Vertex The vertex that has been created . 

176 * / 

177 public Vertex create Vertex ( String label) { 

178 return createVertex ( vertices . size () , label , ) ; 

179 } 

181 /** 

182 * Creates a new vertex with the given label and a maximum initial capacity 

183 * to connect edges to the vertex . 

184 * ©param index 

185 * ©param label 

186 * ©param capacity 

187 * ©return Vertex 

188 * / 
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protected Vertex create Vertex ( final int index, final String label, final int 

capacity ) { 

if ( v e r t i c e s . s i z e ( ) > index &fe ve r t i c e s . get ( index ) != null ) 
191 throw new IllegalArgumentException ( "Invalid Index - Vertex already 

exists - " + index ) ; 
if ( label = null ) 

193 throw new Illegal ArgumentException ( "Label cannot be null" ); 

194 Vertex v = new Vertex( this , index , label , capacity ) ; 

195 vertices . add ( index , v ) ; 

196 return v; 



190 



102 



197 



2 lr> 



} 



199 /** 

200 * Creates an Edge joining the two vertices. 

201 * Oparam from Non— null vertex 

202 * @param to Non— null vertex 

203 * @return Edge 

204 * / 

205 public Edge createEdge ( Vertex from, Vertex to) { 

206 if ( from = null ) 

207 throw new Illegal ArgumentException ( "From vertex is null" ); 
2os if ( to = null ) 

209 throw new IllegalArgumentException ( "To vertex is null" ); 

210 Edge edge = new Edge(this , from , to , edges . size () ) ; 

211 edges . add ( edge ) ; 

212 return edge ; 

213 } 

215 /** 

216 * <p>Returns a string representation of the Graph in the format:</p> 

217 * 

218 * <xmp>nodes { nodel , node2 , . . . , nodeN } 

219 *edges 

220 *{ 

221 * edgel , edge2 , ... edgeE 

222 *}</xmp> 

223 * 

224 * <p>Where nodeN, and edgeE are the string representations of the 
N<sup>th</sup> node 

225 * and E<sup>th</sup> edge respectively . 

226 * 

227 * ©return String 

228 * / 

229 public String toStringQ { 

230 StringBuffer buffer = new S t r ing B uf f e r ( ) ; 

231 buffer . append (" nodes { "); 

232 for (Iterator < Vert ex > vi = vertices . iterator () ; vi. hasNext ( ) ; ) { 

233 b uf f er . append (vi . next () . toString () ) ; 

234 if ( vi . hasNext ( ) ) 

235 buffer . append (" , "); 

236 } 

237 buffer . append ( " }\ nedge s \n{\n "); 

238 for (Iterator <Edge> ei = edges, iterator (); ei. hasNext ( ) ; ) { 

239 b uf f er . append (ei . next ( ) . toStringQ) ; 

240 if ( e i . hasNext () ) 

241 buffer . append (" , "); 

242 } 

243 buffer . append (" \n} ") ; 

244 return buffer . toString () ; 



} 



248 * DFS 

250 private int dfslndex = 0; 
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251 private Vertex dfsRoot = null ; 

253 /** 

254 * Returns the current index used by the DFS algorithm . 

255 * ©return int 

256 * / 

257 public int getDFSIndex ( ) { return dfslndex ; } 

259 /** 

260 * Increments the current index being used by the DFS algorithm . 

261 * / 

262 public void incrementDFSIndex ( ) { dfslndex++; } 

264 /** 

265 * Returns the vertex used as the root of the DFS tree . 

266 * ©return Vertex 

267 * / 

268 public Vertex getDFSRootQ { return dfsRoot ; } 

270 /** 

271 * Sets the vertex used as the root of the DFS tree . 

272 * 

273 * ©param root The non— null vertex , belonging to this graph, which will be 
used 

274 * as the root of the DFS tree . 

275 * ©return 

276 * / 

277 public void setDFSRoot( final Vertex root ) { 

278 if ( root = null ) 

279 throw new IllegalArgumentException ( "Null vertex passed as root." ); 

280 if( root . getGraph ( ) = this ) 

281 dfsRoot = root ; 

282 else 

283 throw new IllegalArgumentException ( "Vertex passed as root does not 
belong to this graph." ); 

284 } 

286 /** 

287 * Data structure to link a Vertex and an Edge Iterator for the 

288 * Edges connected to that Vertex . 

289 * ©author Martyn Taylor 

290 * / 

291 private static class DFS VertexEdgesHolder { 

292 private final Vertex vertex ; 

293 private final Iterator <Edge> edges; 

295 /** 

296 * Creates a holder for the given vertex and the iterator for the 

297 * edges connected to that vertex . 

298 * ©param vertex 

299 * / 

300 private DFS VertexEdgesHolder ( final Vertex vertex ) { 

301 this . vertex = vertex; 

302 this . edges = vertex . getConnectedEdges () . iterator () ; 

303 } 

305 /** 

306 * Gets the vertex . 

307 * ©return 

308 * / 

309 private Vertex get Vertex () { return vertex; } 

311 /** 

312 * Gets the iterator for the edges connected to the subject vertex. 

313 * ©return 
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314 
315 
316 



private Iterator <Edge> getEdgesQ { return edges; } 

} 



318 /** 

319 * <p>Sets the DFS root vertex then performs a Depth— First Search</p> 

320 * 

321 * @param root The non— null vertex , belonging to this graph, which will be 
used 

322 * as the root of the DFS tree . 

323 * / 

324 public void DFS( final Vertex root ) { 

325 setDFSRoot ( root ) ; 

326 DFS ( ) ; 

327 } 

329 /** 

330 * <p>Performs a Depth First Search of the graph from the given vertex and 

331 * calculates the first and second low points for each vertex. </p> 

332 * 

333 * <p>The algorithm also generates a list of uni — d i r e c t i o n al edges connected 
to 

334 * each vertex , such that edges making up the stem of the DFS tree are 
connected 

335 * from parent to child and edges that are not part of the stem (frond edges) 
are 

336 * connected from descendant to ancestor . The algorithm then bucket sorts 
these 

337 * edges so that they are ordered based on first and second low points as 

338 * detailed by Hopcroft and Tarjan.</p> 

339 * 

340 * Oparam root The non— null vertex , belonging to this graph, which will be 
used 

341 * as the root of the DFS tree . 

342 * / 

343 OSuppressWarnings ( " unchecked " ) 

344 public void DFS() { 

345 final Vertex root = getDFSRootQ ; 

346 if ( root = null ) 

347 throw new IllegalArgumentException ( "Root vertex cannot be null." ); 

349 final UnmodifiableLinkList <Edge > [] dfsBucket = new UnmodifiableLinkList [ 
vertexSizeQ * 2 + 1 j; 

350 for ( int i = 0; i < vertexSizeQ * 2 + 1; i++ ) 

351 dfsBucket [ i ] = new UnmodifiableLinkList <Edge >() ; 

353 for ( Vertex vertex: get Vert i ces ( ) ) 

354 vertex . resetDFSIndex () ; 

356 for ( Edge edge: getEdgesQ ) 

357 edge . setDFS Visited ( false ); 

359 dfslndex = 0; 

360 root . setDFSParent ( null ); 

362 LinkList <DFSVertexEdgesHolder> edgelterators = new 
LinkList<DFSVertexEdgesHolder >() ; 

363 edgel t er at o r s . addHead ( new DFS VertexEdgesHolder ( root ) ); 

365 while ( ! edgelterators . isEmpty ( ) ) { 

366 DFS VertexEdgesHolder ve = e dgel t er at or s . getHead ( ) ; 

367 Vertex vertex = ve . get Vertex ( ) ; 

368 Iterator <Edge> edgelterator = ve . getEdges ( ) ; 

369 if ( edge 1 1 er at or . hasNext ( ) ) { 

370 Edge edge = edgel t e r at or . next Q ; 
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371 if ( ! edge . isDFSVisited () ) { 

372 edge . setDFS Visited ( true ); 

373 Vertex otherVertex = edge . getOtherEndFrom ( vertex ) ; 

374 if ( otherVertex . getDFSIndex ( ) = Vertex ,DFS_UNSET ) { 

375 edge .setDFSType( Edge .DFS_STEM ); 

376 other Vertex . setDFSParent ( edge ); 

377 edgel t er at o r s . addHead ( new DFS VertexEdgesHolder ( otherVertex ) 

); 

378 } else { 

379 edge .setDFSType( Edge .DFS_FROND ); 

3so if ( other Vertex . getDFSIndex ( ) < vert ex . getLowPoint 1 ( ) ) { 

381 vertex . setLowPoint2 ( vert ex . get LowPoint 1 ( ) ); 

382 vertex . setLowPoint 1 ( otherVertex . getDFSIndex ( ) ); 

383 } else if ( vert ex . get LowPoint 1 ( ) < other Vertex . getDFSIndex ( ) 
&& otherVertex . getDFSIndex () < vertex . getLowPoint2 ( ) ) { 

384 vertex . setLowPoint2 ( ot her Vert ex . getDFSIndex ( ) ); 

385 } 

386 dfsBucket [ other Vertex . getDFSIndex ( ) * 2 ].addTail( edge ); 

387 } 

388 } 

389 } else { 

390 Edge parentEdge = vert ex . getDFSParent ( ) ; 

391 if ( parentEdge != null ) { 

392 Vertex parent = parentEdge . getOtherEndFrom ( vertex ); 

393 if ( DEBUG_DFS ) System . out . print ( parentEdge + "\tBefore: " + 
parent + " (" + parent . getDFSIndex () + ", " + 

parent . getLowPointl () + ", " + parent . getLowPoint2 ( ) + ")" + "\t" 

+ vertex + " ( " + vertex . getDFSIndex ( ) + ", " + 

vert ex . getLowPoint 1 ( ) + ", " + vertex . getLowPoint2 ( ) + ")"); 

394 if ( vert ex . getLowPoint 1 ( ) < parent . getLowPointl ( ) ) { 

395 parent . setLowPoint2 ( Math.min( vertex . getLowPoint2 () , 
parent . get LowPoint 1 ( ) ) ); 

396 parent . setLowPointl ( vert ex . getLowPoint 1 ( ) ); 

397 } else if ( vert ex . getLowPoint 1 ( ) = parent . getLowPoint 1 ( ) ) { 

398 if ( vertex . getLowPoint2 ( ) < parent . getLowPoint2 ( ) ) 

399 parent . setLowPoint2 ( vert ex . get LowPoint 2 ( ) ); 

400 } else if ( vert ex . getLowPoint 1 ( ) < parent . getLowPoint2 ( ) ) { 

401 parent . setLowPoint2 ( vert ex . getLowPoint 1 ( ) ); 

402 } 

403 if ( DEBUG_DFS ) System . out . println ( "\tAfter: " + parent + " (" 
+ parent . getDFSIndex ( ) + ", " + parent . getLowPoint 1 ( ) + ", " + 
parent . getLowPoint2 () + ")" + "\t" + vertex + " (" + 

vertex . getDFSIndex ( ) + ", " + vert ex . getLowPoint 1 ( ) + ", " + 
vertex . getLowPoint2 ( ) + ")"); 

404 dfsBucket [ vertex . getLowPointl ( ) * 2 + ( vertex . getLowPoint2 ( ) < 
parent . getDFSIndex () ? 1 :0) ].addTail( parentEdge ); 

405 } 

406 edgelterators . removeHead ( ) ; 

407 } 

408 } 

410 for ( UnmodifiableLinkList <Edge> orderedEdges : dfsBucket ) 

411 for ( Edge edge : orderedEdges ) 

412 edge . getDFSFrom ( ) . addDFSAdjacentEdge ( edge ); 

413 } 

416 * Segments 

418 private UnmodifiableLinkList <Segment> segments = null; 

420 /** 

421 * Returns a list of segments. 

422 * ©return UnmodifiableLinkList&lt ; Segment2&gt ; 

423 * / 
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public UnmodifiableLinkList <Segment> getSegments ( ) { return segments; } 

426 /** 

427 * Returns the number of segments . 

428 * / 

429 public int getNumberOfSegments ( ) { return segment s . s i z e ( ) ; } 

431 /** 

432 * <p>Generates a list of segments using the DFS adjacency edges. </p> 

433 * 

434 * <p>{@link Graph#DFS()} must be called before this method. </p> 

435 * / 

436 public void generateSegments ( ) { 

437 if ( getDFSRoot () = null ) 

438 throw new IllegalArgumentException ( "DFS Algorithm must have run first 1 

); 

440 for ( final Vertex vertex: get Vert ices ( ) ) 

441 vertex . setSegment ( null ); 

final LinkList <Iterator <Edge» edgelterators = new 
LinkList <Iterator <Edge>>() ; 

edgelterators . addHead( getDFSRoot () . getDFSAdjacency () . iterator () ) ; 

447 Segment segment = null ; 

448 int index = 0; 

449 segments = new Unmodif iableL inkList <Segment > () ; 

451 while( ! edgelterators . isEmpty ( ) ) { 

452 Iterator <Edge> edgelterator = edgelterators . getHead () ; 

453 if ( edge 1 1 er a t or . hasNext ( ) ) { 

454 Edge edge = edgel t er at or . next ( ) ; 

455 if ( ! ed gel t e r at or . hasNext ( ) ) 

456 edgel t er at or s . removeHead () ; 

457 if ( segment = null ) 

458 segments . addTail ( segment = new Segment ( indexH — h, edge ) ); 

459 else if ( segment . continuesStem ( edge ) ) 

460 segment . addStem ( edge ); 

461 else { 

462 // Handle segments without a cotree edge. 

463 segment, leaf = segment . stem . getTail (). getDFSTo () ; 

464 segments . addTail ( segment = new Segment ( indexH — h, edge ) ); 

465 } 

467 if ( segment . isComplete ( ) ) 

468 segment = null ; 

469 else 

470 edgelterators . addHead ( 
edge . getDFSTo () . getDFSAdjacency ( ) . iterator () ); 

471 } else 

472 edgelterators . removeHead () ; 

473 } 

474 if ( segment != null ) 
segment .leaf = segment . stem . getTail () . getDFSTo ( ) ; 



-175 
476 



} 



479 * Planar Embedding 

481 /** 

482 * The segment that caused the embedding to fail , or null if the graph is 

483 * planar . 

484 * / 

485 private Segment nonPlanarSegment = null ; 
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487 /** 

488 * All the blocks of segments that have been embedded. 

489 * / 

490 private UnmodifiableLinkList <Block> allBlocks = null; 

492 /** 

493 * Checks whether the embedding of the graph succeeded . 

494 * ©return boolean True if the graph is planar, false otherwise. 

495 * / 

« public boolean isPlanarQ { return nonPlanarSegment = null; } 

/ * * 

* Gets a list of all the blocks created during the planar embedding of the 
graph . 

* ©return {©link Unmod if iableLinkLis t }& 1 1 ; { ©link Block}&gt ; The list of 
blocks . 



501 
502 



public UnmodifiableLinkList <Block> get AllBlocks ( ) { return allBlocks; } 



504 /H 

505 * Adds a block of segments to the graph 

506 * @param block The non— null block being added to the graph. 

507 

508 public void addBlock( final Block block ) { 

509 if ( block = null ) 

510 throw new IllegalArgumentException ( "Cannot add a null block." ); 

511 all B locks . addTail ( block ) 

512 } 

514 /** 

515 * Embeds the segments . 

516 

517 public void embedSegments ( ) { 

518 nonPlanarSegment = null ; 

519 allBlocks = new UnmodifiableLinkList <Block >() ; 

520 permutations = new UnmodifiableLinkList <SegmentPermutation >() ; 

522 for ( final Segment segment : segments ) 

523 segment . r e se t C hi 1 d 1 1 e r a t or ( ) 

525 final LinkList <Segment> segmentlterator = new LinkList <Segment >() ; 

526 final Segment initialCycle = segments . getHead ( ) 

527 i n i t i a 1 C y c 1 e . setlsEmbedded ( true ) 

528 segmentlterator . addTail ( initialCycle ); 

530 while ( ! segmentlterator . isEmpty ( ) ) { 

531 Segment segment = segmentlterator . getTail () ; 

532 Segment child = segment . getNextChild ( ) 

533 if ( child != null ) { 

534 if ( DEBUGEMBED ) System . out . println ( "Processing segment: " 
child + " (child of: " + segment + ")" ) 

536 if ( ! segment . embedChildSegment ( child ) ) { 

537 nonPlanarSegment = child 

538 if ( DEBUG_EMBED ) System . out . println ( "Not Embeddable " 
segment . t o S t ring ( ) ) 

539 break ; 

540 } 

541 // if ( ch i Id . hasChildSegment s ( ) ) 

542 segmentlterator . addTail ( child ) 

543 } else { 

544 segment . appendDescendantSegments () 

545 Segment removed = segment It er at or . removeTail ( ) 
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546 if ( DEBUG_EMBED ) System . out . println ( "Segment processed: " + 
segment + " (removed: " + removed + ", remaining: " + 
segmentlterator + ")" ); 

547 } 

548 } 

550 for ( final Block block: allBlocks ) 

551 block . assignBlockToSegments () ; 

553 for ( final SegmentPermutation permutation : permutations ) 

554 permutation . setlsPermutableAboutParent ( ) ; 

555 } 

558 * Permutations 

561 /** 

562 * The list of segment permutations for the embedded graph. 

563 * / 

564 private UnmodifiableLinkList <SegmentPermutation> permutations = null; 

566 /** 

567 * Adds a permutation to the graph . 

568 * @param permutation The permutation to add to the graph . 

569 * / 

570 public void addPermutation ( final SegmentPermutation permutation ) { 
permutations . addTail ( permutation ); } 

572 /** 

573 * Gets the permutable segments that are available for the embedded planar 
graph . 

574 * ©return {©link UnmodifiableLinkList }& 1 1 ;{ @link SegmentPermutation}&gt ; The 
list of permutable segments. 

575 * / 

576 public UnmodifiableLinkList <SegmentPermutation> getPermutations ( ) { return 
permutations ; } 

579 * Ordering 

581 /** 

582 * Generates the embedding for the graph . 

583 * / 

584 public void gener at eEdgeS ides ( ) { 

585 for ( final Segment segment: segments ) 

586 segment . resetChildlterator () ; 

587 for ( final Edge edge : edges ) 

588 edge . resetOrder () ; 

590 final LinkList <Segment> segmentlterator = new LinkList <Segment >() ; 

591 final Segment initialCycle = segments . getHead () ; 

592 Edge ICLeafEdge = null ; 

593 Edge ICOutEdge = null ; 

594 segmentlterator . addTail ( initialCycle ); 

595 initialCycle . setEmbeddedDirection ( Segment . CLOCKWISE ); 

596 for ( final Edge edge: i n i t i a 1 C y c 1 e . getEdges ( ) ) { 

597 if ( edge.isDFSStemQ || ( edge . getDFSTo ( ) = 
i n i t i al C y c le . get Root Vertex () ) ) 

598 edge . getDFSTo (). setEdgeOrderParent ( edge ); 

599 else 

600 ICLeafEdge = edge ; 

601 if ( Graph. DEBUG_ORDER ) System . out . println ( edge . getDFSTo ( ) + 11 : 
Parent - " + edge . getDFSTo (). toOrderedEdgesString ( ) ); 

602 } 
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603 for ( final Edge edge: i n i t i al C y c 1 e . getEdges ( ) ) { 

604 edge . getDFSFrom ( ) . setEdgeOrderStem ( edge ); 

605 if ( ICLeafEdge != null && edge . getDFSFrom ( ) = 
i n i t i al C y c le . get LeafVert ex ( ) ) 

606 ICOutEdge = edge ; 

607 if ( Graph. DEBUG_ORDER ) System . out . println ( edge . getDFSFrom ( ) 
Stem - " + edge . getDFSFrom ( ) . toOrderedEdgesString () ); 

608 } 

609 if ( ICLeafEdge != null ) { 

610 initialCycle. get LeafVert ex () . connect ClockwiseFrom( ICOutEdge , 



} 



ICLeafEdge) 



613 while ( ! segmentlterator . isEmpty ( ) ) { 

614 final Segment segment = segment It er at or . get T ail () ; 

615 final Segment child = segment . getNextChild () ; 

616 if ( child = null ) { 

617 if ( Graph .DEBUG_ORDER ) System . out . println ( "Segment " + segment + 
" : Ordering Complete . " ) ; 

618 if ( segment . getParent ( ) != null ) { 

619 final Unmodif iableL inkList <Edge> edges = segment . getEdges () ; 

620 if ( edges . getTail () . isDFSFrond () ) 

621 segment . getLeafVertex (). orderRemoveEdge ( edges . getTail ( ) ); 

622 segment . getRoot Vertex (). orderRemoveEdge ( edges . getHead ( ) ); 

623 } 

624 segmentlterator. removeTailQ ; 
} else { 

626 if ( Graph .DEBUG_ORDER ) System . out . println ( "Segment " + segment + 
": Ordering Child - " + child ); 

627 final boolean direction = segment . getEmbeddingDirection () ; 

628 final boolean c h i 1 d D i r e c t i o n = child . get S ide ( ) = 
Block. INSIDE? direct ion :! direction; 

629 final UnmodifiableLinkList <Edge> childEdges = c hild . get Edges () ; 

630 final Vertex childRoot = child . getRoot Vertex () ; 

631 final Vertex childLeaf = child . getLeafVertex () ; 

632 child . setEmbeddedDirection ( childDirection ); 

634 for ( final Edge edge: childEdges ) 

635 if ( edge.isDFSStemQ ) { 

636 edge . getDFSTo ( ) . setEdgeOrderParent ( edge ); 

637 if ( Graph ,DEBUG_ORDER ) System . out . println ( edge . getDFSTo ( ) + 
": Parent - " + edge . getDFSFrom ( ) + " - " + 
edge .getDFSToQ . toOrderedEdgesString () ) ; 

} 

for ( final Edge edge: childEdges ) 

640 if ( edge .getDFSFrom () != childRoot ) { 

641 edge . getDFSFrom (). setEdgeOrderStem ( edge ); 

642 if ( Graph .DEBUG_ORDER ) System . out . println ( edge . getDFSFrom ( ) 
+ ": Stem - " + edge . getDFSTo ( ) + " - " + 
edge . getDFSFrom () . toOrderedEdgesStringQ ) ; 

} 

segment . setChildEmbeddedDirection ( childDirection ); 

647 childRoot . orderOutboundEdge ( childEdges . getHead ( ) ); 

648 final Edge childTail = childEdges . get Tail () ; 

649 if ( childTail . isDFSFrond () ) 

650 childLeaf . orderlnboundEdge ( childTail ); 

652 segmentlterator . addTail ( child ); 

653 } 

654 } 

655 } 

/* * 
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658 * Returns a string representation of the cyclic order that vertices 

659 * are connected . 

660 * ©return String 

661 * / 

662 public String to VertexCyclicOrderString ( ) { 

663 final StringBuilder sb = new StringBuilder () ; 
for ( final Vertex vertex : get Vert i ces ( ) ) { 

665 sb . append ( vertex . toString ( ) ); 

666 sb . append ( " : " ) ; 

667 sb . append ( vertex . toOrderedEdgesString ( ) ); 

668 sb. append ( ' \n ' ); 

669 } 

670 return sb . toString () ; 
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} 



674 * Statistics 

677 /** 

678 * Calculates the average segment depth for the graph. 

679 * ©return double The average segment depth. 

680 * / 

681 public double calculate AverageSegmentDepth ( ) { 

682 int depthTotal = 0; 
for ( final Segment segment : segments ) { 

684 segment . setDepthFromParent ( ) ; 

685 depthTotal += segment . getDepth () ; 
} 

687 return (double) depthTotal / segments . s i z e () ; 

} 



CSS 

690 /*< 

691 * Calculates the maximum segment depth for the graph. 

692 * ©return int The maximum segment depth. 

693 * / 

694 public int calculateMaximumSegmentDepth ( ) { 

695 int maxDepth = 0; 
for ( final Segment segment : segments ) { 

697 segment . setDepthFromParent ( ) 

698 if ( segment . getDepth ( ) > maxDepth ) 

699 maxDepth = segment . getDepth ( ) ; 

700 } 

701 return maxDepth; 

702 } 

704 /** 

705 * Calculates the total number of conflicts 

706 * ©return int The maximum segment depth. 

707 * / 

708 public int c ale ul at eT ot al C o n f lie t s ( ) { 

709 int conflicts = 0; 

710 for ( final Segment segment: segments ) 

711 conflicts += segment . getConflictingSegments () . size () 

712 // if ( conflicts != segments . s i z e ( ) — 3 ) System . err . p r i nt 1 n ( 
segments . s i z e ( ) + ", " + conflicts ) 

713 return conflicts / 2; 

714 } 

716 public int calculateNumberOfBlocks ( ) { 

717 int numBlocks = 0; 

718 for ( final Block block : allBlocks ) { 

719 if ( block . hasNoSegmentsInside ( ) &fc block . hasNoSegmentsOutside ( ) ) 

720 continue ; 

721 numBlocks- 
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722 } 

723 return numBlocks ; 

. ! } 

726 public int calculateNumberOfFlippableB locks ( ) { 

727 int numBlocks = 0; 

728 for ( final Block block : allBlocks ) { 

729 if ( block . hasNoSegmentsInside ( ) && block . hasNoSegmentsOutside ( ) ) 

730 continue ; 

731 if ( block . isFlippable ( ) ) 

732 numBlocksH — H; 

733 } 

734 return numBlocks ; 

735 



762 
763 



770 



776 
777 



} 



737 / * * 

738 * Each segment is only added to an existing block if there is a conflict , 

739 * therefore the total number of conflicts indicates the size of each block 

740 * (this should be equal to number of segments — 1 — ) 

741 * ©return 

742 * / 

743 public double calculateAverageBlockSize ( ) { 

744 final int nb = calculateNumberOfBlocks ( ) 

745 final int tc = c ale u lat eT o t al Co nf lie t s ( ) 

746 return (nb = ? :((( double ) tc ) /nb + 1)) 

747 } 

749 /** 

750 * Calculates the average of a segment's depth multiplied by the number of 
children it has . 

751 * ©return double 

752 * / 

753 public double calculateAverageSegmentDepthXChildren ( ) { 

754 int depthTotal = 0; 

755 for ( final Segment segment : segments ) { 

756 segment . setDepthFromParent ( ) ; 

757 depthTotal += ( segment . getDepth ( ) + 1 ) * 
(segment . getChildSegments () . size () + 1); 

758 } 

759 return (double) depthTotal / segments . s i z e () ; 

760 } 



public void pr int DepthsFor AllRoot Vert ices ( ) { 
for ( final Vertex root: vertices ) { 

764 DFS( root ) ; 

765 generateSegments ( ) ; 

766 System . out . pr i nt 1 n ( root . toString ( ) + 1 \t 1 + 
calculateAverageSegmentDepth ( ) ) ; 

767 } 

768 } 



public void printDepthsFor AllRoot Vertices ( final int start , final int end ) { 

771 for ( int i = start ; i <= end && i <= vertices . size () ; i++ ) { 

772 final Vertex root = v e r t i c e s . get ( i ); 

773 DFS( root ) ; 

774 generateSegments () ; 

775 System . out . pr i nt 1 n ( root . toString ( ) + 1 \t 1 + 
calculateAverageSegmentDepth ( ) ) ; 

} 

} 



779 public void print Dept hsXChildrenFor AllRoot Vert ices ( ) { 

780 for ( final Vertex root: vertices ) { 

781 DFS( root ) ; 

782 generateSegments () ; 
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78 4 
785 

787 
788 
789 
790 
791 
792 
793 
794 



798 
799 

801 
802 

803 
804 
805 
806 
807 
808 
809 
810 
811 
812 
813 
814 
815 
816 
817 
818 
819 
820 

822 
823 



82G 
827 
828 



System . out . println ( root . toString ( ) + ' \t ' + 
calculateAverageSegmentDepthXChildren ( ) ) ; 

} 

} 

public void printEdgeStandardDeviation ( ) { 
int sum = 0; 

int sumsq = 0; 

for (Vertex v: get Vert ices ( ) ) { 

int size = v . get ConnectedEdges ( ) . s i ze ( ) ; 
sum += size ; 

sumsq += size* size; 

} 

double std = Math . sqrt (( double ) sumsq/ vertexSize ( ) — (double) 

(sum* sum) / (vertexSize () *vertexSize () ) ) ; 



} 



System . out . println ( vertexSizeQ + "\t" + std ) 



public void pr i nt Ver t ex S izes ( ) { 

j ava . u t i 1 . HashMap<Int eger , Integer> count = new j ava . u t i 1 . HashMap<Int eger 
Integer >() ; 

for (Vertex v: get Ver t ices ( ) ) { 

int size = v . get ConnectedEdges (). s i z e () ; 
if ( count . containsKey ( size ) ) { 

Integer c = count . remove ( size ); 

count. put ( size, c + 1 ); 
} else 

count. put ( size, 1 ); 

} 

int [] orderedCounts = new int [ count . size () ] ; 
int i = 0; 

for ( int c: count . key Set ( ) ) 

orderedCounts [ H — h] = c; 
Arrays . sort ( orderedCounts ) ; 
int [] counts = new int [ count . size () ] ; 
i = 0; 

for( int c: orderedCounts ) { 

counts [H — h] = count . get ( c ); 

} 

for ( i = 0; i < counts . length ; i++ ) 

System . out . pr i nt 1 n ( vertexSize () + "\t" + orderedCounts [ i ] + "\t" + 
counts [ i ] ) ; 

} 

* Speed Testing 



830 


/* * 












831 


* 












832 


*/ 












833 


public 


static 


final 


String 


VERTEX STRING 


" Vertices " ; 


834 


public 


static 


final 


String 


EDGE STRING 


"Edges" ; 


835 


public 


static 


final 


String 


ROOT STRING 


" Root " ; 


836 


public 


static 


final 


String 


START STRING 


= "Timing Started"; 


837 


public 


static 


final 


String 


DFS STRING 


"DFS Completed"; 


838 


public 


static 


final 


String 


GENERATION STRING = 


"Segment Generation Completed 


839 


public 


static 


final 


String 


EMBEDDING_STRING 


= 11 Segment Embedding 




Completed " ; 










840 


public 


static 


final 


String 


EDGE_SIDES_STRING = 


"Edge Sides Generated"; 


8 12 


public 


void t imeP lanarit y Test ( ) { 
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813 
8-14 
845 

817 
818 
849 

851 
852 
853 
851 

856 
857 



} 



if ( vertexSize () > ) 

timePlanarityTest( getVertices().get( ), System .out ) 



862 
863 
864 
865 
806 
867 
868 
869 
870 
871 

873 
874 



87(3 
877 
878 



882 
883 

885 
886 

887 
888 
889 
890 
891 
892 



893 
894 



897 
898 



public void timePlanarityTest ( final Vertex root ) { 
timePlanarityTest ( root, System . out ); 

} 

public void timePlanarityTest ( final PrintStream writer ) { 
if ( vertexSize () > ) 

timePlanarityTest( getVertices().get( ), writer ); 

} 

private static final boolean SHOW COMPILATION TIMES = false; 
private static final boolean SHOW CLASS LOADING = false; 

private static final j ava . lang . management . CompilationMXBean compMXBean 
SHOW_COMPnATION_TIMES?java . lang . management . ManagementFactory . getCompilationMXB 
private static final j ava . lang . management . ClassLoadingMXBean classMXBean = 
SHOW_CLASS_LOADlNG? j ava . lang . management . ManagementFactory . getClassLoadingMXBean 

public void silen t P 1 an ar i t y Tes t ( final Vertex root ) { 
setDFSRoot ( root ) ; 
silentPlanarityTest () ; 

} 

public void silen t P 1 an ar i t y Tes t ( ) { 

DFS(); 

generateSegments () ; 
embedSegments ( ) ; 
generateEdgeSides ( ) ; 

} 

public void timePlanarityTest ( final Vertex root , final PrintStream writer ) { 
if ( writer = null ) throw new IllegalArgumentException ( "Output stream 
cannot be null" ) ; 



an ( ) : null : 
() mull; 



if ( root != null ) 

setDFSRoot ( root ) ; 
writer . println ( ROOT_STPJNG 



getDFSRoot () . toString () ) 



final long classes = 

SHOW_CLASS_LOADING? classMXBean . getTotalLoadedClassCount ( ) : ; 
final long unloaded = 

SHOW_CLASS_LOADING? classMXBean . getUnloadedClassCount () :0; 
long startCompTime = 0; 
long doneCompTime = ; 

writer . println ( START_STRING ); 
if ( SHOW_CDlVjT j nATION_TIMES ) startCompTime = 
compMXBean. getTotalCompilationTime () ; 
long start = System . nanoTime ( ) ; 
DFS ( ) ; 

long done = System . nanoTime ( ) ; 

if ( SHOW_CD1VjT j KATION_TIMES ) { 

doneCompTime = compMXBean . getTotalCompilationTime ( ) ; 
writer . println ( DFS_STRJNG + ": " + (done - start) + " - " 
((doneCompTime - startCompTime) * 1000000) + " = " + (done 
(doneCompTime - startCompTime) * 1000000) ); 

} else 

writer . println ( DFS_STPJNG + ": " + (done - start) ); 

if ( SHOW_CD1VjT j jTATION_TIMES ) startCompTime = 
compMXBean. getTotalCompilationTime () ; 
start = System . nanoTime ( ) ; 
generateSegments ( ) ; 



start 
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89 9 
900 
901 
902 



903 
904 



90 7 
908 
909 
910 
911 
912 



913 
914 



917 
918 
919 
920 
921 
922 



923 
924 

926 
927 
928 
929 

930 
931 
932 
933 
934 
935 
936 
937 
938 
939 
940 
941 
942 
943 
944 
915 



950 
951 



// 
/* 



done = System . nanoTime () ; 

if ( SHOW_COMPEATON_TTMES ) { 

doneCompTime = compMXBean . getTotalCompilationTime ( ) ; 

writer . println ( GENERATION_STRING + ": " + (done - start) + " - " - 
((doneCompTime - startCompTime ) * 1000000) + " = " + (done - start 
(doneCompTime - startCompTime) * 1000000) ) ; 
} else 

writer . println ( GENERATION_STRING + ": " + (done - start) ); 

if ( SHOW_COMPILATION_TIMES ) startCompTime = 
compMXBean. getTotalCompilationTime () ; 
start = System . nanoTime () ; 
embedSegments ( ) ; 
done = System . nanoTime ( ) ; 
if ( SHOW_COMPILATION_TIMES ) { 

doneCompTime = compMXBean . getTotalCompilationTime ( ) ; 

writer . println ( EMBEDDING_STRING + ": " + (done - start) + " - 11 + 
((doneCompTime - startCompTime) * 1000000) + " = " + (done - 
(doneCompTime - startCompTime) * 1000000) ) ; 
} else 

writer . println ( EMBEDDING_STRING + ": " + (done - start) ); 

if ( SHOW_COMPEATON_TTMES ) startCompTime = 
compMXBean. getTotalCompilationTime () ; 
start = System . nanoTime () ; 
generateEdgeSides ( ) ; 
done = System . nanoTime () ; 
if ( SHOW_COMPHATION_TIMES ) { 

doneCompTime = compMXBean . getTotalCompilationTime ( ) ; 

writer . println ( EDGE_SIDES_STRJNG + ": " + (done - start) + 

((doneCompTime - startCompTime) * 1000000) + " = " + (done - 

(doneCompTime - startCompTime) * 1000000) ); 
} else 

writer . println ( EDGE_SIDES_STRTNG + ": " + (done - start) ) 



start 



start 



if 



} 



( SHOW_CLASS_LOADING ) { 

final long doneClasses = classMXBean . getTotalLoadedClassCount ( ) ; 
final long doneUnloaded = classMXBean . getUnloadedClassCount () ; 
writer . println ( "Classes Loaded: " + (doneClasses — classes) + " 
Classes Unloaded: " + (doneUnloaded — unloaded) ); 



writer . println ( getSegments () . get Head () .to!ndentedString( 



) ) 



for ( final Vertex vertex 
writer . print ( vertex + 
boolean first = true; 
for ( final Edge edge: 
if ( first ) 

first = false; 
else 

writer, print ( ", 



jet Vert ices ( ) ) { 

": [" ); 

vertex . getEdgeOrder ( ) ) { 



) 



writer . print ( edge . getOtherEndFrom ( vertex ) ) 

} 

writer, println ( ']' ); 



//*/ 
} 



public static void main( String [] args ) { 
Graph g ; 

// g = new Graph( "nodes { 0, A, B, C, D, E, F, G, H, I, J }\n" + 

// "edges { (0, A), (0, B) , (0, C) , (0, D) , (0, E) , (0, F) , (0, G) , (0. 

H) , (0, I) , (0, J) } " ); 
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954 
955 
956 

958 
959 
960 
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// g = new Graph( "nodes { A, B, C, D, E, F, G, H }\nedges { (A,B) , (A,C) , 
(A,D) , (A,E) , (A,F) , (A,G) , (B,C) , (C,D) , (C,F) , (D,E) , (D,G) , (E,F) , (E,G) , 
(C,H), (H, A) }" ); 

int size = 5000; 

g = new mgtaylor . graph . graphTypes . PlanarMultiWheelGraph ( size , 3, true); 
for ( int i = 0; i < size ; i++ ) 

g . timePlanarity Test ( g . get Vertices (). get ( i ) ); 

// System . out . println ( g ); 

// for ( Vertex vertex: g . get Vert ic es ( ) ) 

// System . out . println ( vertex + "\t" + vertex . getDFSIndex ( ) + "\t" + 

vertex . getLowPointl () + "\t" + vertex . getLowPoint2 ( ) + "\t" + 
vert ex . getDFS Adj acency ( ) ); 

/ / System .out.println( " \ t " + g . get Segments () . to String ( ",\n\t" ) ); 
} 

//*/ 
} 



D.2.4 mgtaylor. graph. GraphEvent 



package mgtaylor . graph ; 
import java. util .*; 
public class GraphEvent { 



public static 

public static 

public static 

public static 

public static 

public static 

public static 



final int 

final int 

final int 

final int 

final int 

final int 

final int 



NEW GRAPH 


= 1; 


NODE ADDED 


= 2; 


NODE DELETED 


= 4; 


NODE EDDIED 


= 8; 


EDGE ADDED 


= 16; 


EDGE DELETED 


= 32; 


EDGE EDDIED 


= 64; 



private final Collection <GraphObject> changedltems ; 
private final int status ; 



29 
30 



33 
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public GraphEvent ( final 
this. status = status; 

changedltems = new ArrayList <GraphObject >( 
changedltems . add ( obj ect ) ; 

} 



int status , final GraphObject object) { 

i ); 



public GraphEvent ( final int status 
this . status = status ; 
changedltems = objects; 

} 



final Collection <GraphObject> objects) { 



public int getStatus() { return status; } 

public Collection <GraphObject> getChangedltems ( ) { return changedltems; } 

public Collection <Vertex> getChangedNodes ( ) { 

LinkedList <Vertex> nodes = new LinkedList <Vertex > () ; 
for (GraphObject object: changedltems) 
if (object instanceof Vertex) 
nodes . add (( Vertex ) object); 
return nodes ; 

} 

public Collection <Edge> getChangedEdges ( ) { 

LinkedList <Edge> edges = new LinkedList <Edge >() ; 
for (GraphObject object: changedltems) 
if (object instanceof Edge) 
edges . add (( Edge ) object); 
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return edges : 

} 

} 



D.2.5 mgtaylor. graph. GraphListener 



package mgtaylor . graph ; 

public interface GraphListener { 

public void graphChanged ( GraphEvent event) 

} 



D.2.6 mgtaylor. graph. GraphObject 



package mgtaylor . graph ; 



import j ava . u t i 1 . C o llec t ion 



public interface GraphObject { 

// public boolean isConnectedTo ( Vertex vertex); 

public boolean isConnectedTo ( Edge edge); 

// public Collection <Vertex> get Connect ed Vert ices () ; 

public Collection <Edge> getConnectedEdges ( ) ; 

public String toStringQ; 

} 



D.2.7 mgtaylor. graph. Path 



package mgtaylor . graph ; 
import java. util . Iterator ; 

import mgtaylor . datastructures . UnmodifiableLinkList ; 
public class Path extends PathSegment { 

/* * 

* The root (first) vertex of the segment. 

*/ 

protected final Vertex root ; 

/* * 

* The leaf (last) vertex of the segment. 

*/ 

protected Vertex leaf = null ; 

* Creates a segment (or the start of a segment) from the given edge. 

* The segment will be complete once a frond edge has been added. 

* (Qiparam index A unique sequential identifier for the Segment. 

* @param edge The first edge of the segment. 



public Path( final Edge edge ) { 
addStem( edge ) ; 
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this . root = edge . getDFSFrom ( ) ; 

} 

/* * 

* Returns the graph containing the segment. 

* ©return Graph The graph containing the segment. 

*/ 

public Graph getGraphQ { return root . getGraph ( ) ; } 



/** 

* Returns the root vertex of the segment; this is the first vertex in the 

* sequence of connected unidirectional DFS edges . 

* ©return Vertex The root vertex . 

*/ 

©Override 

public Vertex getRoot Vertex ( ) { return root; } 



/* * 

* Returns the DFS index of the root vertex . 

* ©return int The DFS index of the root vertex . 

*/ 

©Override 

public int getRoot VertexDFSIndex ( ) { return root . getDFSIndex ( ) ; } 



/* * 

* Returns the leaf vertex of the segment; this is the last vertex in the 

* sequence of connected unidirectional DFS edges. 

* ©return Vertex The leaf vertex . 

* / 

©Override 

public Vertex getLeafVertex ( ) { return leaf; } 



/ * * 

* Returns the DFS index of the leaf vertex. 

* ©return int The DFS index of the leaf vertex. 

*/ 

©Override 

public int getLeafVertexDFSIndex ( ) { return 1 e af . getDFSIndex () ; } 



* Returns the segment that the root vertex belongs to (or null if the 

* root vertex is the root vertex of the initial cycle). 

* ©return 

* / 

©Override 

public Segment getParentQ { 

final Segment segment = root . getSegment ( ) ; 
if ( segment . getRoot Vertex ( ) = root ) 

return null ; 
return segment ; 

} 

/* * 

* The second lowest DFS index reachable from any vertex on the stem of this 
segment. If the segment 

* is a single frond edge then this defaults to the root vertex 's DFS index; 
otherwise it is the 

* low point 2 index for the first vertex of the stem (after the root vertex). 

* ©return int The DFS index of the second low point vertex . 

* / 

©Override 

public int getLowPoint2Index ( ) { 
if ( hasStem ( ) ) 

return stem . get Head () . getDFSTo () . getLowPoint2 () ; 
return getRoot VertexDFSIndex ( ) ; 
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} 

93 / * * 

94 * Adds the edge to the stem of the segment . 

95 * ©param edge 

96 * / 

97 (©Override 

98 public void addStem( final Edge edge ) { 

99 super . addStem ( edge ); 

101 if ( edge . isDFSFrond () ) 

102 leaf = edge . getDFSTo () ; 

103 else if ( ! edge . isDFSStem ( ) ) 

104 throw new Illegal ArgumentException ( "Edge has not been visited by DFS 
algorithm: " + edge ) ; 

105 } 

107 /** 

108 * Checks to see if the segment is fully formed. 

109 * ©return boolean 

no */ 

in public boolean isCompleteQ { return leaf != null; } 

113 /** 

114 * Gets the path from the root vertex to the second low point vertex . 

115 * ©return 

116 */ 

117 public Path getPathToLowPoint2 ( ) { 

us final int lowPt2 = getLowPoint2Index () ; 

no Edge e = stem . getHead ( ) ; 

120 Vertex to = e . getDFSTo ( ) ; 

121 Path path = new Path( e ) ; 

123 while ( to . getDFSIndex () != lowPt2 ) { 

124 final Iterator <Edge> edges = to . getDFS Adjacency (). i t e r at o r () ; 

125 to = (e = edges . next () ). getDFSTo () ; 

126 while ( to . getLowPointl () != lowPt2 && to . getLowPoint2 ( ) != lowPt2 ) 

127 to = (e = edges . next ()) .getDFSTo () ; 

128 path . addStem ( e ); 

129 } 

130 return path ; 

131 } 

133 /** 

134 * Checks whether this and the given path (that must both be attached to the 
same 

135 * segment) conflict when only considering the paths to their leaf and low 
point 2 

136 * vertices. 

137 * 

138 * ©param path 

139 * ©return 

140 * / 

141 public boolean conflictsWith ( final Path path ) { 

142 if ( t his . get Parent ( ) != path . getParent ( ) ) 

143 throw new IllegalArgumentException ( "Paths do not have the same 
segment . " ) ; 

144 if ( this . getRootVertexDFSIndex () < path . getRoot VertexDFSIndex ( ) ) { 

146 } else if ( this . getRootVertexDFSIndex () > path . getRoot VertexDFSIndex ( ) ) { 

148 } else { 

149 if ( this . getLeafVertexDFSIndex ( ) < path . getLeafVertexDFSIndex ( ) ) { 

150 return t his . getLowPoint 2Index ( ) > path . getLeafVertexDFSIndex () ; 
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} else if ( t his . getLeafVertexDFSIndex ( ) > path . getLeafVertexDFSIndex () 
) { 

152 return path . getLowPoint2Index ( ) > this . getLeafVertexDFSIndex () ; 

153 } else { 

154 return t his . get LowPoint 2Index ( ) < t his . getRoot VertexDFSIndex ( ) &fe 

155 path . getLowPoint2Index ( ) < path . getRoot VertexDFSIndex () ; 

} 

157 } 

158 return false ; 

} 

160 /** 

161 * Gets the path to Low Point 2 vertex starting from the deepest possible 
vertex on the stern. 

162 * ©return 

163 * / 

164 public Path getPathStubToLowPoint2 ( ) { 

165 final int lowPt2 = getLowPoint2Index () ; 

166 Edge e = stem . getHead ( ) ; 

167 Vertex to = e . getDFSTo ( ) ; 

168 Path path = null ; 

169 boolean hasBranched = false ; 

171 while ( to . getDFSIndex () != lowPt2 ) { 

172 final Iterator <Edge> edges = to . getDFSAdjacency ( ) . i t e r a t o r ( ) ; 

173 boolean firstEdge = true; 

174 to = (e = edges . next () ). getDFSTo () ; 

175 while ( to . getLowPointl () != lowPt2 && to . getLowPoint2 ( ) != lowPt2 ) { 

176 to = (e = edges . next ()) .getDFSTo () ; 

177 firstEdge = false ; 

178 } 

179 if ( ! firstEdge &fe ! hasBranched ) { 

180 path = new Path( e ) ; 

181 hasBranched = true ; 

182 } else if ( hasBranched ) 

183 path . addStem ( e ); 

184 } 

185 return path ; 

186 } 



188 



public Path extendPathBackTo ( final Segment segment ) { 

189 Vertex r = root ; 

190 final UnmodifiableLinkList <Edge> edges = new Unmodif iableLinkList <Edge > () : 

191 while ( r . getSegment ( ) != segment ) { 

192 final Edge e = r . getDFSParent ( ) ; 

193 edges . addHead ( e ); 

194 r = e . getDFSFrom ( ) ; 
} 

196 Path path = null ; 

197 for ( final Edge e: edges ) 

198 if ( path = null ) 

199 path = new Path( e ) ; 

200 else 

201 path . addStem ( e ); 

202 for ( final Edge e: stem ) 

203 if ( path = null ) 
path = new Path( e ) ; 

205 else 

206 path . addStem ( e ); 

207 return path ; 



208 
209 



} 
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D.2.8 mgtaylor. graph. PathSegment 

package mgtaylor . graph ; 

import mgtaylor . datastructures . LinkList ; 



import mgtaylor . datastructures . UnmodifiableLinkList ; 
public class PathSegment { 

* The list of edges that comprise the segment. 

* / 

protected final UnmodifiableLinkList <Edge> stem = new 
Unmodif iableLinkList <Edge > () ; 

/* * 

* Creates a segment (or the start of a segment) from the given edge. 

* The segment will be complete once a frond edge has been added. 

* / 

public PathSegment ( ) {} 

/* * 

* Returns the root vertex of the segment; this is the first vertex in the 

* sequence of connected unidirectional DFS edges. 

* ©return Vertex The root vertex . 

*/ 

public Vertex getRoot Vertex ( ) { return 

stem . isEmpty ()?null:stem. get Head ( ) . getDFSFrom ( ) ; } 

/* * 

* Returns the DFS index of the root vertex . 

* ©return int The DFS index of the root vertex . 

*/ 

public int getRoot VertexDFSIndex ( ) { return 

stem . isEmpty ( ) ? — 1: stem . get Head ( ) . getDFSFrom ( ) . getDFSIndex ( ) ; } 

/ * * 

* Returns the leaf vertex of the segment; this is the last vertex in the 

* sequence of connected unidirectional DFS edges . 

* ©return Vertex The leaf vertex . 

* / 

public Vertex getLeafVertex ( ) { return 

stem . isEmpty () ?null : stem . get Tail () . getDFSTo () ; } 

/* * 

* Returns the DFS index of the leaf vertex. 

* ©return int The DFS index of the leaf vertex. 

*/ 

public int getLeafVertexDFSIndex ( ) { return 

stem . isEmpty () ?-l:stem . get Tail () . getDFSTo () . getDFSIndex ( ) ; } 

/* * 

* Returns the segment that the root vertex belongs to (or null if the 

* root vertex is the root vertex of the initial cycle). 

* ©return 

*/ 

public Segment getParentQ { 

final Vertex root = getRoot Vertex ( ) ; 

final Segment segment = root . getSegment ( ) ; 

if ( segment . getRoot Vertex ( ) = root ) 

return null ; 
return segment ; 

} 
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* The second lowest DFS index reachable from any vertex on the stem of this 
segment. If the segment 

* is a single frond edge then this defaults to the root vertex 's DFS index; 
otherwise it is the 

* low point 2 index for the first vertex of the stem (after the root vertex) 

* ©return int The DFS index of the second low point vertex . 

*/ 

63 public int getLowPoint2Index ( ) { 

64 i f ( hasStem ( ) ) 
return stem . getHead ( ) .getDFSToQ . getLowPoint2 ( ) ; 

return getRoot VertexDFSIndex ( ) ; 

} 

/* * 

* Gets the last vertex in the stem. 

* ©return 

* / 

public Vertex getLastStemVertex ( ) { return 

stem. getTail () . getDFSFrom ( ) ; } 

public boolean continuesStem ( final Edge edge ) { 
if ( edge = null ) 

throw new IllegalArgumentException ( "Invalid null edge" ); 

return ( stem . isEmpty ( ) || edge . getDFSFrom ( ) = stem . get T ail (). getDFSTo ( ) 

); 

} 

81 / * * 

82 * Adds the edge to the stem of the segment . 

* ©param edge 

* / 

85 public void addStem( final Edge edge ) { 

86 if ( ! continuesStem ( edge ) ) 
throw new IllegalArgumentException ( "Edge does not connect to most 
recent stem edge: " + stem . get T ail ( ) + "->" + edge ); 

stem . addTail ( edge ); 

} 

/* * 

93 * Checks whether the segment has a stem and is not just a single frond edge. 

94 * ©return 

*/ 

public boolean hasStem() { return 

stem . getHead ( ) . isDFSStem ( ) ; } 

/** 

* Gets the edges 

100 * / 

101 public UnmodifiableLinkList <Edge> getEdgesQ { return stem; } 

103 /** 

104 * Gets the stem vertices for the segment. 

105 * ©return {©link L inkL ist }& 1 1 ; { ©link Vertex}&gt ; The vertices comprising 
the stem of the segment . 

106 * / 

107 public UnmodifiableLinkList <Vertex> getStemVertices ( ) { 

108 final UnmodifiableLinkList <Vertex> stemVertices = new 
UnmodifiableLinkList <Vertex >() ; 

109 for ( Edge edge : stem ) 

no if ( edge != stem . get Tail ( ) ) 

in stem Vertices . addTail ( edge . getDFSTo ( ) ); 

112 return stemVertices ; 

} 



113 
114 
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D.2.9 mgtaylor. graph. Segment 

< 

package mgtaylor . graph ; 
import java. util . Iterator ; 

import mgtaylor . datastructures . UnmodifiableLinkList ; 
import mgtaylor . datastructures . LinkList ; 

public class Segment extends Path { 

public static final boolean DEBUG SET SIDES = false; 

public static final boolean DEBUG OPJDER = false; 

public static final boolean CLOCKWISE = true; 

public static final boolean ANTICLOCKWISE = ICLOCKWISE; 

/ * * 

* A unique sequential identifier for the segment. 

* / 

private final int index; 

/* * 

* The parent segment . 

* The segment that contains the root vertex in it's stem. 

* / 

private final Segment parent ; 

* The previous segment . 

* The previous child segment of the same parent; or if the parent has no 
children 

* then the parent segment . 

*/ 

private final Segment previous ; 

/* * 

* Creates a segment (or the start of a segment) from the given edge. 

* The segment will be complete once a frond edge has been added. 

* @param index A unique sequential identifier for the Segment. 

* @param edge The first edge of the segment. 

* / 

public Segment ( int index, Edge edge ) { 
super ( edge ) ; 

this . index = index; 
this . parent = root . getSegment ( ) ; 

if ( parent = null ) { 

root . setSegment ( this ); 

previous = null ; 
} else { 

previous = 

parent. getChildSegmentsQ . isEmpty () ?parent : parent . getChildSegments () . getT 
parent . addChildSegment ( this ); 

} 

} 

/* * 

* Returns the unique index for the segment. 

* ©return 
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public int getSegmentlndex () { return index; } 

60 / * * 

61 * The parent segment is the segment which first contains the segment 's root 
vertex in it's 

* stem; the exception for this is the initial cycle which has a null parent 
element otherwise the 

* parent would be s e 1 f — r e f e r e n t i a 1 . 

* ©return Segment The segment that is the parent for this segment or null 
in the case of the 

* initial cyclic segment's parent. 

* / 

public Segment getParentQ { return parent; } 

/* * 

* The previous segment is the segment prior to this one in the parent 's list 
of child segments; if 

* this is the first child of the parent then the previous segment is the 
parent and if this 

* segment is the initial cycle then the previous segment is null. 

* ©return Segment The previous segment . 

*/ 

public Segment get P r e vious ( ) { return previous; } 

/** 

* The segment which first contains this segment's leaf vertex. 
79 * ©return 



so 



public Segment getLeafSegment ( ) { return 1 e af . get Segment () ; } 



83 / * * 

84 * Adds the edge to the stem of the segment . 

* ©param edge 

* / 

87 public void addStem( final Edge edge ) { 

88 super . addStem ( edge ); 

if ( edge.isDFSStemQ ) { 

edge . getDFSTo () . setSegment ( this ); 

92 } 

93 } 

96 * Child Segments 

/* * 

100 * The segments that have root vertices on this segment's stem. 

101 * / 

102 private final UnmodifiableLinkList <Segment> childSegments = new 
UnmodifiableLinkList <Segment >() ; 

104 /** 

105 * 

106 * / 

107 private Iterator <Segment> c h i 1 d 1 1 e r a t o r = null; 

109 /** 

110 * 

111 */ 

112 private Iterator <Segment> permutationlterator = null; 

114 /** 

115 * Adds a child segment to this (the parent's) list of child segments. 
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lie * ©param segment 

117 */ 

us protected void addChildSegment ( Segment segment ) { 
no childSegments . addTail ( segment ); 

120 } 

122 /** 

123 * Checks whether the segment has children . 

124 * ©return 

125 * / 

126 public boolean hasChildSegments ( ) { 

127 return ! childSegments . isEmpty () ; 

128 } 

130 /** 

131 * Returns the list of child segments. 

132 * ©return {©link L inkL ist }& 1 1 ; { ©link Segment}&gt ; 

133 * / 

134 public UnmodifiableLinkList <Segment> getChildSegments ( ) { 

135 return childSegments ; 

136 } 

138 /** 

139 * Resets the iterator over the child segments. 

140 * / 

141 public void r es et C h i ldl t er at o r ( ) { 

142 c h i 1 d 1 1 e r a t o r = childSegment s . i t er at o r ( ) ; 

143 permutationlterator = null; 

144 } 

146 /** 

147 * Gets the next child from a stored iterator over the list of child segments. 

148 * <P> 

149 * This method is first called by {©link Graph#embedSegments ( ) } and the 
segments 

150 * will not have any permutations set and they will be visited in the order 
they 

151 * were generated; it is during that method invocation when segments will be 
added to 

152 * permutation groups, if required. 

153 * <P> 

154 * When this method is called by {©link Graph#generateEdgeSides ( ) } , if the 
segments 

155 * are not members of a permutable group then they will be visited in the 
order in 

156 * which they were generated. If the segments are part of a permutable group 
then 

157 * they will be visited in the current permutation order and once all the 
segments 

158 * in the permutation are visited then the visiting order will return to the 
next 

159 * permutation in the default order (assuming that is not also part of a 
different 

160 * permutable group). 

161 * ©return Segment The next child segment or null if there are no more 
children . 

162 * / 

163 public Segment getNextChild ( ) { 

164 if ( c h i 1 d 1 1 e r a t or = null ) throw new IllegalArgumentException ( "Child 
iterator has not been reset before use . " ) ; 

165 if ( c h i 1 d 1 1 e r a t o r . hasNext ( ) ) { 

166 final Segment next = c h il d 1 1 er a t o r . next ( ) ; 

167 if ( permutationlterator != null ) { 

168 while ( per mut at ionlt er at or . hasNext ( ) ) { 

169 final Segment pnext = permutationlterator . next () ; 
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170 if ( pnext != this ) 

171 return pnext ; 

172 } 

173 permutationlterator = null; 

174 } 

175 if ( next . getPermutation ( ) != null ) { 

176 permutationlterator = 
next.getPermutationQ .getPermutationQ . iterator () ; 

177 while ( permutationlterator . hasNext ( ) ) { 

178 final Segment pnext = per mut at ionlt er at or . next ( ) ; 

179 if ( pnext != this ) 

180 return pnext ; 

181 } 

182 throw new IllegalArgumentException ( "Non-parent segment not found in 
permutation . " ) ; 

183 } 

184 return next ; 
} 

return null ; 



185 
186 
187 



190 * Blocks 

193 /** 

194 * The block that the segment has been embedded in. This will be finalised 

195 * once all segments have been embedded and blocks will not be concatenated. 

196 * / 

197 private Block embeddedBlock = null ; 

199 /** 

200 * Gets the blocks containing the child segments (and their descendants). 

201 * / 

202 protected final LinkList <Block> childBlocks = new LinkList <Block >() ; 

204 /** 

205 * Returns the block the segment has been embedded in . 

206 * ©return Block The block that the segment has been embedded in . 

207 * / 

208 public Block getEmbeddedBlock ( ) { return embeddedBlock; } 

210 /** 

211 * Sets the block the segment has been embedded in . 

212 * @param block 

213 * / 

214 public void setEmbeddedBlock ( final Block block ) { 

215 if ( block = null ) throw new Illegal ArgumentException ( "Block argument 
cannot be null . " ) ; 

216 embeddedBlock = block ; 

JJT } 

219 /** 

220 * Returns the last block in the list of blocks containing child segments. 

221 * ©return Block The last block in the list of blocks containing child 
segments . 

222 * / 

223 public Block get Last ChildBlock ( ) { return chi Id B locks . get T ai 1 () ; } 

225 /** 

226 * Adds the given block to the list of child blocks. 

227 * @param block A non— null block 

228 * / 

229 public void addChildBlock ( final Block block ) { childBlocks . addTail ( block 

); } 
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231 /** 

232 * Removes the last block from the list of child blocks. 

233 * ©see Block#concatenate ( ) 

234 * / 

public void removeLastChildBlock ( ) { chi Id B locks . removeTail () ; } 



2:ir, 



final 


int 


NOT EMBEDDABLE 


0: 




final 


int 


CONFLICT INSIDE 







final 


int 


CONFLICT BOTH SIDES 




i 


final 


int 


EMBED ON INSIDE 




2 


final 


int 


FLIP EMBED ON INSIDE = 


3; 




final 


int 


EMBED ON OUTSIDE 


4; 




final 


int 


NEW BLOCK 


5; 





239 * Planarity Testing 

241 // public stat 

242 public stat 

243 public stat 

244 public stat 

245 public stat 

246 public stat 

247 public stat 

249 /** 

250 * 

251 * / 

252 private boolean isEmbedded = false ; 

254 /** 

255 * The last segment that was embedded. 

256 * / 

257 private Segment lastEmbeddedSegment = null ; 

259 /** 

260 * Returns the last embedded segment . 

261 * ©return Segment 

262 * / 

263 protected Segment getLastEmbeddedSegment ( ) { 

264 return lastEmbeddedSegment ; 

265 } 

267 /** 

268 * Checks whether the segment is embedded. 

269 * ©return boolean True if the segment has been embedded (or if no attempt 
has been 

270 * made to embed the segment) , false if the embedding has 
failed . 

271 * / 

272 public boolean isEmbedded () { return isEmbedded; } 

274 /** 

275 * Sets whether the segment has been embedded. 

276 * (Bparam isEmbedded True is the segment has been embedded, false otherwise. 

277 * / 

278 public void setlsEmbedded ( final boolean isEmbedded ) { 

279 this . isEmbedded = isEmbedded; 

280 } 

282 /** 

283 * Sets the last embedded segment. 

284 * (Bparam segment 

285 * / 

286 public void setLastEmbeddedSegment ( final Segment segment ) { 
lastEmbeddedSegment = segment ; } 



288 /** 
289 

290 * @param segment 

291 * @param block 
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292 * ©return 

293 * / 

294 public int checkEmbedding ( Segment segment, Block block ) { 

295 final boolean inConflicts = block . insideConflictsWith ( segment ); 

296 final boolean outConflicts = block . outsideConflictsWith ( segment ) 
if ( inConflicts ) { 

298 final Segment inside = block . get L ast Inside () ; 

299 inside . addConflictingSegment ( segment ); 

300 segment . addConflictingSegment ( inside ); 
} 

if ( outConflicts ) { 

303 final Segment outside = block . get Last O ut side () ; 

304 outside . addConflictingSegment ( segment ) ; 

305 segment . addConflictingSegment ( outside ) ; 



301 
302 



3011 



309 
310 



:> lr, 



} 



307 if ( Graph .DEBUG_EMBED ) System . out . println ( "Embedding Segment: " + 
segment . toString () + " on " + toString () + " (" + inConflicts + " " + 
( block . isEmptylnside ()?" null ": block . get Last Inside (). toSt ring () ) + ", " + 
outConflicts + " " + 

(block . isEmptyOutside () ? "null " : block . getLastOutside () . toString () ) + ") ") 

308 if ( inConflicts &fe outConflicts ) return CONFLICT_BOTH_SIDES ; 
if ( ! inConflicts && ! o u t Co nf li c t s ) return NEW BLOCK; 
if ( inConflicts ) { 

311 if ( segment . isFlippable () ) return EMBED_ON_OUTSK)E; 

312 else if ( block . isFlippable () ) return FLIP_EMBED_ON_INSIDE ; 
else return CONFLICT INSIDE ; 

) else return EMBED ON INSIDE; 



313 
314 
315 } 



317 /** 

318 * Tests whether a segment, that is a child of this segment, is embeddable . 

319 * @param segment The non— null segment, that is a child of this segment, 

320 * that is being embedded. 

321 * ©return True if the segment has been successfully embedded, false 

322 * otherwise. 

323 * / 

324 public boolean embedChildSegment ( Segment segment ) { 

325 if ( segment = null ) throw new Illegal ArgumentException ( 
"Cannot embed a null segment." ); 

if ( segment . getParent ( ) != this ) throw new IllegalArgumentException ( 
"Cannot embed a segment on a non-parent segment." ); 
Block childBlock = getLastChildBlock ( ) ; 

329 / * 

330 * Fully embed all the segments in the last block that have a leaf 

331 * segment with an equal or higher DFS index than the passed child 

332 * segment's root vertex's DFS index. If all segments in the block 

333 * are fully embedded then remove this block from the list (the 

334 * block will remain in the graph's list of blocks)and repeat with 

335 * the next latest block until either all blocks are processed or 

336 * a block is found with segments that are not fully embedded. 

337 * / 

338 while ( childBlock != null ) { 

339 if ( ! childBlock . embedTo( segment . getRoot VertexDFSIndex ( ) ) ) 

340 break ; 

341 removeLastChildBlock ( ) ; 

342 childBlock = get Last ChildBlock () ; 

343 } 



// 



346 // Check for permutations with previously embedded segment. 

347 // 

348 if ( ( segment . getLeafVertexDFSIndex ( ) < 
segment . getRoot VertexDFSIndex () ) 

&fe ( lastEmbeddedSegment != null) 
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&& ( lastEmbeddedSegment . getRoot VertexDFSIndex ( ) = 
segment . getRoot VertexDFSIndex ( ) ) 

&& ( lastEmbeddedSegment . getLeafVertexDFSIndex ( ) = 
segment . getLeafVertexDFSIndex () ) 

&&: ( lastEmbeddedSegment . getLowPoint2Index ( ) >= 
lastEmbeddedSegment . getRoot VertexDFSIndex ( ) ) 

&& ( segment . getLowPoint2Index ( ) >= segment . getRoot VertexDFSIndex () ) 

) { 

354 // 

355 // If Child and lastEmbeddedChild have the same start and end points 
and 

// do not have a low point 2 vertex on the parent ( if they do have a 
low 

357 // point 2 vertex on the parent they must be embedded adjacent to the 

358 // parent and may be flippable but are not permutable) . 

359 // In this case the segments are permutable and the child must be 
embeddable 

// within the previous segment (same start and end so do not overlap 
and 

361 // neither connects to an ancestor). 

362 / / 

364 if ( ! lastEmbeddedSegment . isPermutable ( ) ) { 

365 lastEmbeddedSegment . permutation = new SegmentPermutation ( 
lastEmbeddedSegment , segment ) ; 

366 getGraph ( ) . addPermutation ( lastEmbeddedSegment . getPermutation ( ) ) 

367 } else 

368 lastEmbeddedSegment . getPermutation (). addTail ( segment ); 
segment . permutation = lastEmbeddedSegment . getPermutation () ; 

372 if ( childB lock . get L as t Ins ide ( ) = lastEmbeddedSegment ) 

373 childBlock . addSegmentlnside ( segment ); 

374 else if ( c hildB lock . get Last O ut side ( ) = lastEmbeddedSegment ) 

375 childBlock . addSegmentOutside ( segment ); 

376 else 

377 throw new IllegalArgumentException ( "Permutable segment " + 

segment + " (" + segment . getRoot VertexDFSIndex ( ) + ", " + 
segment . getLeafVertexDFSIndex ( ) + ", " + 

segment . getLowPoint2Index ( ) + ") - cannot match last embedded 
segment " + lastEmbeddedSegment + " (" + 
lastEmbeddedSegment . getRoot VertexDFSIndex ( ) + ", " + 
lastEmbeddedSegment . getLeafVertexDFSIndex ( ) + ", " + 
lastEmbeddedSegment . getLowPoint2Index ( ) + ") to either side of 
last block. <" + child B lock . get Las t Inside ( ) + ", " + 
childBlock . get Las t O ut side () + ">" ); 

379 lastEmbeddedSegment = segment ; 

380 segment . setlsEmbedded ( true ); 

381 return true ; 

382 } 

384 / * 

385 * If the parent has no blocks (that are not already fully embedded) 
* then the segment can be added without conflict . 

*/ 

388 if ( childBlock = null ) { 

389 new Block ( segment ) ; 

390 segment . setlsEmbedded ( true ); 

391 return true ; 

392 } 



386 
387 



394 / * 



395 



* Otherwise check the last block for conflicts 



396 
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397 final int status = checkEmbedding ( segment, childBlock ); 

398 boolean embedSide = Block . INSIDE ; 

399 boolean embedSideEmpty = false ; 

400 switch ( status ) { 

401 case CONFLICT_INSIDE : 

402 segment . setlsEmbedded ( false ); 

403 return false ; 

404 case CONFLICT_BOTH_SIDES : 

405 segment . setlsEmbedded ( false ); 

406 return false ; 

407 case NEW_BL0CK: 

408 new Block ( segment ); 

409 segment . setlsEmbedded ( true ); 

410 return true ; 

411 case EMBED_ON_OUTSIDE: 

412 embedSide = Block . OUTSIDE ; 

413 embedSideEmpty = childB lock . isEmpty Outside () ; 

414 break ; 

415 case FLIP_EMBED_ON_INSIDE : 

416 childBlock . flip () ; 

417 case EMBED_ON_INSIDE: 

418 embedSideEmpty = childBlock . isEmptylnside () ; 

419 } 

420 while ( embedSideEmpty &&; child B lock . get P re vious ( ) != null ) { 

421 final Block prevBlock = childB lock . get Pre vious () ; 

422 boolean prevEmbedSide = Block . INSIDE ; 

424 switch ( checkEmbedding ( segment, prevBlock ) ) { 

425 case CONFLICT_INSIDE: 

426 segment . setlsEmbedded ( false ); 

427 return false ; 

428 case CONFLICT_BOTH_SIDES: 

429 segment . setlsEmbedded ( false ); 

430 return false ; 

431 case NEW_BLOCK: 

432 if ( embedSide = Block. INSIDE ) 

433 childBlock . addSegmentlnside ( segment ); 

434 else 

435 childBlock . addSegmentOutside ( segment ); 

436 segment . setlsEmbedded ( true ); 

437 return true ; 

438 case FLD°_EMBED_ON_INSIDE : 

439 prevBlock . flip () ; 

440 case EMBED_ON_INSIDE: 

441 prevEmbedSide = Block . INSIDE ; 

442 break ; 

443 case EMBED J3N_OUT31DE: 

444 prevEmbedSide = Block . OUTSIDE ; 

445 } 

446 if ( prevEmbedSide != embedSide ) { 

447 / * 

448 * One block inside , one outside means that the segment 

449 * must be flippable. 

450 * / 

451 if ( pre vBlock . i s F 1 i p p ab le ( ) ) { 

452 prevBlock . flip () ; 

453 } else if ( chi ldB lock . is F lipp able ( ) ) { 

454 childBlock . flip () ; 

455 embedSide = ! embedSide ; 

456 } else { 

457 segment . setlsEmbedded ( false ); 

458 return false ; 
} 



159 
460 



} 



461 childBlock = childB lock . concatenate () ; 
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462 } 

463 if ( embedSide = Block. INSIDE ) 

464 childBlock . addSegmentlnside ( segment ) 

465 else 

466 childBlock . addSegmentOutside ( segment 

467 segment . setlsEmbedded ( true ); 

468 return true ; 

469 } 



-171 
-172 
173 
-17-1 
475 
476 
-177 
-17S 
479 
-ISO 
-181 
-182 
-183 
-184 
-185 
-186 
187 
-188 
-189 
490 
491 

493 
494 
495 

496 
-197 
-198 
199 



/* * 

* Appends the segments on the inside of all the non— f 1 i p p ab 1 e 

* child blocks to the last child block of this segment's parent. 

* <p> 

* Flippable blocks are not appended as the segments within 

* that block are all flippable and, hence, only connect to 

* the root stem or leaf of their parent and do not connect 

* to an ancestor. This means that they cannot conflict with 

* a later embedded descendant of an ancestor. 

* / 

public void appendDescendantSegments ( ) { 
if ( getParentQ = null ) 
return ; 

final LinkList <Segment> segments = new LinkList <Segment > () ; 
while ( ! chi Id B locks . isEmpty ( ) ) { 

Block childBlock = ch ildB locks . removeTail () ; 

if ( ! childBlock . isFlippable () ) 

segments . addAHHead ( childB lock . get InsideS egments ( ) ); 

} 

get P arent (). get Last ChildB lock (). appendSegments After ( this, segments ); 

} 

/* * 

* Checks whether this segment conflicts with a previously embedded segment. 

* Oparam segment A non— null segment to compare with this segment for a 
conflict . 

* ©return boolean 

* / 

public boolean conflictsWith ( Segment segment ) { 

if ( segment = null ) throw new IllegalArgumentException ( "Segment 
argument cannot be null" ) ; 



501 
502 
503 
504 

505 
506 
507 

508 
509 
510 

511 
512 

514 
515 
516 

517 
518 
519 



) { 



// 



final boolean conflict ; 

if ( this . getSegmentlndex ( ) < segment . getSegmentlndex ( ) 
final int leaf = t his . getLeafVertexDFSIndex ( ) ; 
conflict = segment . getLeafVertexDFSIndex ( ) < leaf && leaf < 
segment . get Root Vert exDFS Index ( ) ; 
} else if ( this . getSegmentlndex ( ) > segment . getSegmentlndex ( ) ) { 
final int leaf = segment . getLeafVertexDFSIndex () ; 
conflict = this . getLeafVertexDFSIndex ( ) < leaf &fe leaf < 
this . getRootVertexDFSIndex () ; 
} else 

conflict = false; 
System . out . p r in 1 1 n ( toPat hString ( ) + ". conflictsWith ( " + 
segment . toPathString ( ) + ") = " + conflict); 
return conflict ; 

} 

/ * * 

* Checks whether the segment can be embedded on either side of the parent. 

* ©return boolean True if the segment can be embedded on either side , 
false otherwise . 

* / 

public boolean i s F 1 i p p ab le ( ) { 

return parent != null &fe ( getLeafVertexDFSIndex ( ) >= 
parent . getRootVertexDFSIndex () 
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|| ( getLeafVertexDFSIndex () = 
parent . getLeafVertexDFSIndex () 

&&: getLowPoint2Index () >= 

parent . getRoot VertexDFSIndex ( ) ) ); 



526 * Ordering 

528 /** 

529 * The side of the parent segment on which this segment has been embedded. 

530 * / 

531 private boolean embeddingSide = Block . INSIDE ; 

533 /** 

534 * The direction that the segment is embedded. 

535 * / 

536 private boolean embeddingDirection = CLOCKWISE; 

538 /** 

539 * The direction that the current child segment is being embedded. 

540 * 

541 * / 

542 private boolean childEmbeddingDirection = CLOCKWISE; 

544 /** 

545 * Sets the side of the parent segment on which this segment has been 
embedded . 

546 * @param side Value matches either Block. INSIDE or Block . OUTSIDE . 

547 * / 

548 public void setSide( final boolean side ) { embeddingSide 
side ; } 

550 /** 

551 * Returns the side of the parent segment on which this segment has been 

552 * embedded . 

553 * ©return boolean Returned value matches either Block. INSIDE or 
Block .OUTSIDE. 



55.1 



5G5 



570 
571 



I / 



555 public boolean getSideQ { 

556 if ( getEmbeddedBlock ( ) = null || ! getEmbeddedBlock ( ) . is In ver t ed ( ) ) 

557 return embeddingSide; 

558 



return ! embeddingSide : 



559 } 



561 /** 

562 * Sets the direction that the segment is embedded. 

563 * @param direction 

564 * / 

public void setEmbeddedDirection ( final boolean direction ) { 
embeddingDirection = direction; } 



567 /** 

568 * Gets the direction the segment is embedded. 
* ©return boolean Returned value matches either Segment . CLOCKWISE or 
Segment .ANTICLOCKWISE. 



public boolean getEmbeddingDirection ( ) { return 

embeddingDirection ; } 



573 /** 

574 * Sets the direction that the segment is embedded. 

575 * Oparam direction 

576 * / 
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577 public void setChildEmbeddedDirection ( final boolean direction ) { 

578 childEmbeddingDirection = direction ; 

579 if ( getParentQ != null ) { 

580 root.setChildEmbeddingDirection( stem.getHeadQ, direction ); 

581 if ( stem . getTail () . isDFSFrond () ) 

582 leaf.setChildEmbeddingDirection( stem . getTail (), direction ); 
} 



583 



584 } 

586 /** 

587 * Gets the direction the current child of the segment is being embedded. 

588 * ©return boolean Returned value matches either Segment . CLOCKWISE or 
Segment . ANTICLOCKWISE . 

589 * / 

590 public boolean get ChildEmbeddingDirect ion ( ) { return 
childEmbeddingDirection ; } 

593 * Permutations 

private SegmentPermutation permutation = null ; 

public SegmentPermutation getPermutation ( ) { return permutation; } 

600 public void setPermutation ( final SegmentPermutation p ) { 

601 this . permutation = p; 

602 } 

public boolean isPermutable ( ) { return permutation != null; } 

606 public boolean isPermutableWithParent ( ) { 

607 return isPermutable ( ) &fe 

608 getEmbeddedBlock ( ) != null && 

609 getEmbeddedBlock (). isFlippable ( ) && 

610 getEmbeddedBlock () .isEmptyOutsideQ ; 

611 } 

614 * Non— planarity 

617 /* * 

618 * The segments that conflict with this segment during embedding. 

619 * / 

620 private final UnmodifiableLinkList <Segment> conflictingSegments = new 
UnmodifiableLinkList <Segment >() ; 

622 /** 

623 * Add a conflict with another segment. 

624 * Oparam segment The non— null conflicting segment 

625 * / 

626 public void addConflictingSegment ( final Segment segment ) { 

627 if ( segment = null ) throw new IllegalArgumentException ( "Cannot 
conflict with a null segment." ); 

628 conflictingSegments . addTail ( segment ); 

629 } 

631 /** 

632 * Get the list of conflicting segments. 

633 * ©return 

634 * / 

635 public UnmodifiableLinkList <Segment> getConflictingSegments ( ) { return 
conflictingSegments ; } 
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638 * Statistics 

640 private int depth = 0; 

642 /** 

643 * Gets the depth of the segment within the segment tree . 

644 * ©return int The depth of the segment within the segment tree . 

645 * / 

646 public int getDepthQ { return depth; } 

648 /** 

649 * Sets the depth equal to the parent segment 's depth incremented by one. 

650 * / 

651 public void setDepthFromParent ( ) { 

652 if ( getParentQ = null ) 

653 depth = 0; 

654 else 

655 depth = get P arent ( ) . getDepth ( ) + 1; 

656 } 

659 * String Output 

661 /** 

662 * Returns a string representation of the root , stem and leaf 

663 * vertices. 

664 * 

665 * ©return String 

666 * / 

667 public String toStringQ { 

668 StringBuffer b = new S t r ingB uf f er ( ) ; 

669 toBufferedString ( b ); 

670 return b. toStringQ; 

671 } 

673 private void t oB uf f er ed S t r i ng ( StringBuffer b ) { 

674 b . append ( 1 [ ' ) ; 

675 b. append ( root ); 

676 for ( final Edge e : stem ) { 

677 b . append ( " , " ) ; 

678 b. append ( e.getDFSToQ ); 

679 } 

680 b . append ( 1 ] ' ) ; 

681 } 

683 private void toBufferedlndentedString ( StringBuffer buffer , String indent , 
int d, String indentlncrement ) { 

684 buf fer . append ( indent ); 

685 for (int i = 0; i < d; i^+ ) 

686 buffer . append ( indentlncrement ); 

687 toBufferedString ( buffer ); 

688 buffer . append ( " (" ); 

689 buffer . append( getSide Q = Block . INSIDE? 1 I ':' 1 ); 

690 buffer . append ( ")\n" ); 

691 for ( Segment child : childSegments ) 

692 child . toB uf fer edlndentedS t ring ( buf fer , indent, d+1, indentlncrement); 

693 } 

695 public String toIndentedString ( String indent , String indentlncrement ) { 

696 StringBuffer buffer = new S t r ing B uf f e r ( ) ; 

697 toBufferedlndentedString ( buffer , indent , 0, indentlncrement ) ; 

698 return buffer . toString Q ; 

699 } 



APPENDIX D. JAVA SOURCE CODE 315 



701 
702 

703 
704 
705 
706 
707 
708 
709 
710 
711 
712 
713 
711 
715 
716 
717 
718 
719 
720 
721 
722 
723 
724 
725 
720 
727 
728 
729 
730 
731 

732 
733 
734 



public int toLaTeXString ( StringBuffer buffer 
java. util . HashMap<Segment 
segmentMap , 
int indent , 



java . lang . Character> 





int line 






boolean 


showSide ) { 


append ( 


"\t\t\\node 


C" ); 


append ( 


segmentMap . 


get ( this ) ) ; 


append ( 


" ) at ( " ) ; 




append ( 


indent ) ; 




append ( 


" Wunit , - " 


); 


append ( 


line ) ; 




append ( 


"Wunit) 


[ label ={ [name = " ); 


append ( 


segmentMap . 


get ( this ) ) ; 


append ( 


" ' ,style=noderect]right :\\SquashFont{} 



Block .INSIDE? ' I 



'0' ); 



toBufferedString ( buffer ); 
if (showSide) { 

buffer . append ( " (" ); 

buffer . append ( getSide() 

buffer . append ( ")\n" ); 

} 

buffer . append( "}] 0;\n" ); 

if ( t his . get P arent ( ) != null ) { 

buffer . append ( "\t\t\\draw (node cs:name=" ); 

buffer . append ( segmentMap . get ( this . getParent ( ) ) ); 

buffer . append ( "', anchor = south west) I- (" ); 

buffer . append ( segmentMap . get ( this ) ); 

buffer . append ( ");\n" ); 

} 

line = line + 1; 

for ( Segment child : childSegments ) 

line = child . toLaTeXString ( buffer , segmentMap, indent 

showSide ) ; 
return line ; 



1 , line 



D.2.10 mgtaylor. graph. SegmentPermutation 



package mgtaylor . graph ; 

import mgtaylor . datastructures . PermutableUnmodifableLinkList ; 

public class SegmentPermutation extends PermutableUnmodifableLinkList <Segment> { 
private static final boolean DEBUG = false; 

private final Segment parentSegment ; 

private boolean isPermutableAboutParent = false ; 

public SegmentPermutation ( final Segment... array ) { 

if ( array, length = ) throw new IllegalArgumentException ( "Cannot 
initialise a segment permutation with no segments." ); 

for ( Segment element : array ) 

addTail ( element ) ; 
parentSegment = array [ ]. getParent () ; 

if ( DEBUG ) System . out . println ( " S egment Permut at ion ( ) : " + parentSegment 
+ " , "+ this ) ; 

} 

public Segment getParentSegment ( ) { return parentSegment; } 
public int get Tot alPermut at ions ( ) { return cons t r ai n t s . s i z e ( ) = 
1? super .get Tot alPermut at ions () / 2 : super .get Tot alPermut at ions (); } 
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©Override 

public void handleSwap( final Segment earlier , final Segment later ) { 
if ( earlier = parentSegment ) 

later . setSide ( Block. INSIDE ); 
else if ( later = parentSegment ) 

earlier . setSide ( Block . OUTSIDE ); 

} 

©Override 

public void nextPermutation ( ) { 

if ( c ons t r ain t s . s i z e ( ) = 1 &fe 

get CurrentPermut ation ( ) >= super . get Tot alPermut at ions () /2 — 1 ) 
jumpToPermutation ( ); 
else 

super . nextPermutation () ; 

} 

©Override 

public void previousPermutation ( ) { 
if ( c ons t r ain t s . s i z e ( ) = 1 &fe 

get Current Permutation ( ) <= ) 
jumpToPermutation ( super . getTotalPermutations () /2 — 1 ); 
else 

super . previousPermutation () ; 

} 



©Override 

public void jumpToPermutation ( final int p ) { 
super . jumpToPermutation ( p ); 
orderPermutationsWithParent ( ) ; 

} 

public boolean isPermutableWithParent ( ) { 
return isPermutableAboutParent ; 

} 



public void setlsPermutableAboutParent ( ) { 
if ( DEBUG ) System . out . println ( 

" Segment Permut at i on . set I sPermut abl e About Par ent () : " + this + ", " + 

parentSegment + " (" + isPermutableAboutParent + ")"); 
if ( parentSegment != null && ! isPermutableAboutParent ) { 
Segment segment = getHead() ; 
if ( segment . isPermutableWithParent ( ) ) { 
isPermutableAboutParent = true; 
addHead ( parentSegment ); 
} else if ( parent Segment . get P arent ( ) = null && 

parentSegment . getChildSegments (). getHead ( ) = segment &&: 
segment . getEmbeddedBlock (). hasNoSegmentsOutside ( ) ) { 
addHead ( parentSegment ) ; 
isPermutableAboutParent = true ; 
addConstraint ( parentSegment , segment ) ; 
} else 

isPermutableAboutParent = false ; 

} 

} 

public void orderPermutationsWithParent ( ) { 
if ( parentSegment = null ) 
return ; 

boolean beforeParent = true; 

for ( Segment segment: getPermutation ( ) ) { 
if ( segment = parentSegment ) 

beforeParent = false ; 
else if ( beforeParent ) { 
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segment . setSide ( Block . OUTSIDE ) 
} else { 

segment . setSide ( Block. INSIDE ); 

87 } 

88 } 
} 

} 



D.2.11 mgtaylor. graph. Vertex 



package mgtaylor . graph ; 
import j ava . u t i 1 . Array List ; 

import mgtaylor . datastructures . UnmodifiableLinkList ; 
import mgtaylor . datastructures . LinkList ; 

public class Vertex implements GraphObject { 

* The graph the vertex belongs to . 

* / 

private final Graph graph; 

/* * 

15 * The vertex's index within the graph's array of vertices. 

16 * graph. getVertices().get( this. index ) = this 

*/ 

private final int index; 

/* * 

* The maximum number of edges that can be connected to the vertex . 

* / 

private final int capacity ; 

/** 

* The id of the vertex . 

* / 

private final String id ; 

/* * 

31 * The array of edges connected to the vertex . 

32 */ 

private final ArrayList <Edge> connectedEdges ; 

35 / * * 

36 * Creates a vertex in the graph. 

* Qparam graph The graph the vertex is part of. 

* @param index The index of the vertex within the graph's array of 
vertices . 

* @param id The label for the vertex. 

* @param capacity The number of edges the vertex is assumed to be 
connected to . 

*/ 

public Vertex( final Graph graph, final int index, final String id, final int 

capacity ) { 

if ( graph = null ) throw new Illegal ArgumentException ( "Graph argument 
cannot be null . " ) ; 

if ( id = null ) throw new IllegalArgumentException ( "Id argument 
cannot be null . " ) ; 

if ( capacity < ) throw new IllegalArgumentException ( "Capacity 

argument cannot be negative." ); 
this. graph = graph; 
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this . index = index; 

this .id = id ; 

this . capacity = capacity; 

connectedEdges = new ArrayList <Edge>( capacity ); 

} 

/* * 

* The graph containing the vertex. 

* ©return Graph 

* / 

public Graph getGraphQ { return graph; } 

/ * * 

* Gets the index of the vertex within the graph's array of vertices. 

* ©return 

*/ 

public int getlndex Q { return index; } 

/** 

* The string representation of the vertex. 

•/ 

public String toStringQ { return id; } 

/ * * 

* The number of edges connected to the vertex . 

* ©return int 

*/ 

public int size () { return connectedEdges . s i z e () ; } 

/* * 

* Returns the edges connected to the vertex . 

* ©return ArrayList&lt ; Edge&gt ; 

* / 

public ArrayList <Edge> getConnectedEdges ( ) { return connectedEdges; } 

/* * 

* Connects the given edge to the vertex . 

* ©param edge — A non— null edge that contains this vertex . 

* ©return int — The index within the Vertex's array of edges 

* corresponding to the location of the edge. 

*/ 

public int connectTo( final Edge edge ) { 

if ( edge = null ) throw new IllegalArgumentException 

"Edge cannot be null." ); 

if ( connectedEdges . s i z e ( ) >= capacity ) throw new 

Illegal ArgumentException ( "Vertex has reached capacity: " + toStringQ + 
" , " + edge . toString () ) ; 

if ( ! edge . contains ( this ) ) throw new IllegalArgumentException 

"Edge does not connect to this vertex." ); 
connectedEdges . add ( edge ); 
return connect edEdges . s i z e ( ) — 1; 

} 

/* * 

* Checks to see if the edge contains this vertex. 

* ©param Edge — A non— null edge 

* ©return boolean 

* / 

©Override 

public boolean isConnectedTo ( final Edge edge ) { 

if ( edge = null ) throw new IllegalArgumentException ( "Edge cannot 

be null . " ) ; 

return edge . contains ( this ); 

} 
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ios * DFS 

no public static final int DFS UNSET = -1; 

112 /** 

113 * Depth First Search Index for the vertex 

114 * This is a sequentially incremented identifier 

115 

116 private int dfslndex = DFS_UNSET 

118 /** 

119 * DFS Index for the lowest possible vertex reachable by 

120 * traversing descendants and back edges of the DFS tree 

121 

122 private int lowPointl = DFS_UNSET; 

124 /** 

125 * DFS Index for the second lowest possible vertex reachable 

126 * by traversing descendants and back edges of the DFS tree 

127 * / 

128 private int lowPoint2 = DFS_UNSET; 

130 /** 

131 * Edge connecting the vertex to its parent in the DFS tree 

132 

133 private Edge dfsParent = null ; 

135 /** 

136 * The edges in the DFS tree that are outbound from the current 

137 * edge . 

138 * / 

139 private UnmodifiableLinkList <Edge> dfsAdjacency = null; 

141 /** 

142 * Resets the DFS index of the vertex . 

143 
144 
145 
146 



public void resetDFSIndex ( ) 
dfslndex = DFS_UNSET; 

} 



148 /** 

149 * Returns the DFS index of the vertex . 

150 * ©return int 

151 * / 

152 public int getDFSIndex ( ) { return dfslndex; } 

154 /** 

155 * Compares to see if this vertex has a lower DFS index than the given vertex. 

156 * iQparam vertex 

157 * ©return 

158 * / 

159 public boolean lessThan( final Vertex vertex ) { 

160 return t his . getDFSIndex ( ) < vertex . getDFSIndex ( ) ; 

161 } 

163 /** 

164 * Compares to see if this vertex has a greater DFS index than the given 
vertex . 

165 * ©param vertex 

166 * ©return 

167 

168 public boolean greaterThan ( final Vertex vertex ) { 

169 return t his . getDFSIndex ( ) > vertex . getDFSIndex ( ) ; 

170 } 
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public boolean greaterThanOrEqualTo ( final Vertex vertex ) { 
return t his . getDFSIndex ( ) >= vertex . getDFSIndex ( ) ; 



172 /** 

173 * Compares to see if this vertex has a lower or equal DFS index than the 
given vertex . 

174 * ©param vertex 

175 * ©return 

176 * / 

177 public boolean lessThanOrEqualTo ( final Vertex vertex ) { 

178 return t his . getDFSIndex ( ) <= vertex . getDFSIndex () ; 

179 } 

181 /** 

182 * Compares to see if this vertex has a greater or equal DFS index than the 
given vertex . 

183 * ©param vertex 

184 * ©return 

185 * / 
186 
187 

188 } 

190 /** 

191 * Compares the vertices to find the one with the lowest DFS index. 

192 * ©param vertices 

193 * ©return 

194 * / 

195 public static Vertex min( final Vertex... vertices ) { 

196 if ( v e r t i c e s . lengt h = ) throw new IllegalArgumentException ( "Zero 
vertices." ) ; 

197 Vertex min = vertices [0] ; 

198 for ( int i = 1; i < ve rt i c e s . lengt h ; i++ ) 

199 if ( ve r t i c e s [ i ] . lessThan ( min ) ) 

200 min = vertices [i]; 

201 return min; 

202 } 

204 /** 

205 * Compares the vertices to find the one with the highest DFS index. 

206 * ©param vertices 

207 * ©return Vertex 

208 * / 

209 public static Vertex max( final Vertex . . . vertices ) { 

210 if ( v e r t i c e s . lengt h = ) throw new IllegalArgumentException ( "Zero 
vertices." ); 

211 Vertex max = vertices [0] ; 

212 for ( int i = 1; i < ve rt i ce s . lengt h ; i++ ) 

213 if ( ve r t i c e s [ i ] . greaterThan ( max ) ) 

214 max = vertices [i]; 

215 return max; 

216 } 

218 /** 

219 * Returns the first DFS low point. 

220 * ©return int 

221 * / 

222 public int getLowPointl ( ) { return lowPointl; } 

224 /** 

225 * Returns the second DFS low point . 

226 * ©return int 

227 * / 

228 public int getLowPoint2 ( ) { return lowPoint2 ; } 

230 /** 

231 * Sets the first DFS low point for the vertex. 
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232 * (Bparam int index 

233 
234 



public void setLowPoint 1 ( final int index ) { lowPointl = index; } 



236 /** 

237 * Sets the second DFS low point for the vertex . 

238 * (Bparam int index 

239 * / 

240 public void setLowPoint2 ( final int index ) { lowPoint2 = index; } 

242 /** 

243 * Returns the edge to the parent vertex in the DFS tree . 

244 * ©return Edge 

245 * / 

246 public Edge getDFSParent ( ) { return dfsParent ; } 

248 /** 

249 * Sets the Edge linking the vertex to its parent in the 

250 * DFS tree . 

251 * @param Edge edge 

252 * / 

253 public void setDFSParent ( final Edge edge ) { 

254 dfsParent = edge; 

255 dfslndex = lowPointl = lowPoint2 = graph . getDFSIndex ( ) ; 

256 graph . incrementDFSIndex ( ) ; 

257 dfsAdjacency = new UnmodifiableLinkList <Edge > () ; 

258 } 

260 /** 

261 * Adds an edge to the vertex , such that it is an outbound uni — d i r e c t i o n al 
edge used 

262 * to create the DFS palm tree . 

263 * 

264 * (Bparam edge — Non— null edge 

265 * / 

266 public void addDFSAdjacentEdge ( final Edge edge ) { 

267 if ( edge = null ) 

268 throw new IllegalArgumentException ( "Edge cannot be null." ); 

269 dfsAdjacency . addTail ( edge ); 

270 } 

272 /** 

273 * Gets the list of outbound edges used to create the DFS palm tree. 

274 * 

275 * ©return {©linkplain UnmodifiableLinkList}&lt ; { @link Edge}&gt ; 

276 * / 

277 public UnmodifiableLinkList <Edge> getDFS Adj acency ( ) { 

278 return dfsAdjacency; 

279 } 

282 * Segment 

284 private Segment segment = null ; 

286 /** 

287 * Returns the segment where this vertex is part of the stem. 

288 * ©return Segment 

289 * / 

290 public Segment getSegmentQ { return segment; } 

292 /** 

293 * Sets the segment where this vertex is part of the stem. 

294 * @param segment 

295 * / 
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296 public void setSegment ( final Segment segment ) { this, segment = segment; } 

299 * Order 

302 /** 

303 * <p>The first inbound DFS edge; typically this links the vertex to it's 
parent 

304 * in the DFS tree but in the case of the root vertex , which has no parent , 

305 * it is the frond edge terminating the first (and cyclic) segment. This edge 
i s 

306 * used as the first reference point to order the other edges connected to 
this 

307 * vertex.<p> 

308 * / 

309 private Edge orderParentEdge = null ; 

311 /** 

312 * The first outbound edge from the vertex within the DFS tree. 

313 * / 

314 private Edge orderStemEdge = null ; 

317 /** 

3is * Returns the edge that links the vertex to it 's parent in the DFS tree; in 

the 

319 * case of the root vertex , which does not have a parent vertex , this is the 
frond 

320 * edge terminating the initial (cyclic) segment. 

321 * ©return Edge 

322 * / 

323 public Edge getEdgeOrderParent ( ) { return orderParentEdge; } 

325 /** 

326 * Sets the edge that links the vertex to it 's parent in the DFS tree; in the 

327 * case of the root vertex , which does not have a parent vertex , this is the 
frond 

328 * edge terminating the initial (cyclic) segment. 

329 * Oparam edge 

330 * / 

331 public void setEdgeOrderParent ( final Edge edge ) { 

332 if ( edge = null ) throw new IllegalArgumentException ( "Cannot 
order a null edge . " ) ; 

333 if ( ! edge . contains ( this ) ) throw new IllegalArgumentException ( "Edge 
does not connect to this vertex." ); 

334 orderParentEdge = orderStemEdge = edge ; 

335 } 

337 / * * 

338 * Returns the edge that is the first outbound edge from the vertex in the 
DFS tree 

339 * (and the vertex's outbound edge contained in this vertex's segment). 

340 * ©return 

341 * / 

342 public Edge getEdgeOrderStem ( ) { return orderStemEdge; } 

344 /** 

345 * Returns the edge that is the first outbound edge from the vertex in the 
DFS tree 

346 * (and the vertex's outbound edge contained in this vertex's segment). 

347 * ©return 

348 * / 

349 public void setEdgeOrderStem ( final Edge edge ) { 
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if ( edge = null ) throw new IllegalArgumentException ( "Cannot 

order a null edge . " ) ; 

if ( ! edge . contains ( this ) ) throw new IllegalArgumentException ( "Edge 
does not connect to this vertex." ); 

352 if ( orderParentEdge = null ) { 

353 orderParentEdge = orderStemEdge = edge ; 
} else { 

355 orderStemEdge = edge ; 

356 orderParentEdge . setOrder Anticlockwise ( this, edge ); 
} 



357 
358 



365 
366 



} 



360 /** 

361 * Returns the edge that is ordered clockwise from the given edge 

362 * connected to this vertex. 

363 * @param edge An edge that is connected to this vertex. 

364 * @return Edge 



public Edge getClockwiseFrom ( final Edge edge ) { 

367 return edge . getOrderClockwiseFrom ( this ); 

368 } 

370 / * * 

371 * Returns the edge that is ordered anti — clockwise from the given edge 

372 * connected to this vertex. 

373 * @param edge An edge that is connected to this vertex. 

374 * ©return Edge 

375 * / 

376 public Edge get AntiClockwiseFrom ( final Edge edge ) { 

377 return edge . getOrder AntiClockwiseFrom ( this ); 

378 } 

380 /** 

381 * Orders the ordering edge so that it is clockwise from the reference edge. 

382 * @param referenceEdge 

383 * @param orderingEdge 

384 * / 

385 public void connectClockwiseFrom ( final Edge referenceEdge , final Edge 
orderingEdge ) { 

if ( orderingEdge = null ) throw new 

Illegal ArgumentException ( "Edge being ordered cannot be null." ); 
if ( ! orderingEdge . contains ( this ) ) throw new 

Illegal ArgumentException ( "Edge " + toStringQ + ":" + orderingEdge + " 
being ordered does not connect to this vertex." ); 
if ( orderingEdge . isOrdered About ( this ) ) throw new 

Illegal ArgumentException ( "Edge " + toStringQ + ":" + orderingEdge + " 
being ordered has already been ordered. " + referenceEdge ); 
if ( referenceEdge = null ) throw new 

Illegal ArgumentException ( "Edge used to determine order position cannot be 
null . " ) ; 

if ( ! referenceEdge . contains ( this ) ) throw new 

Illegal ArgumentException ( "Edge " + toStringQ + ":" + referenceEdge + " 
used to determine order position does not connect to this vertex." ); 
if ( ! referenceEdge . isOrderedAbout ( this ) ) throw new 

Illegal ArgumentException ( "Edge " + toStringQ + ":" + referenceEdge + " 
used to determine order position has not been ordered. " + orderingEdge ); 
if ( orderParentEdge = null ) throw new 

IllegalArgumentException ( "Cannot order the given edge until both parent 
and stem edge have been set . " ) ; 

if ( orderStemEdge = null ) throw new 

Illegal ArgumentException ( "Cannot order the given edge until the stem edge 
has been set . " ) ; 

394 referenceEdge . setOrderClockwise ( this, orderingEdge ); 



395 



} 
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397 /*< 

398 * Orders the ordering edge so that it is anti — clockwise from the reference 
edge . 

399 * @param referenceEdge 

400 * Oparam orderingEdge 

401 

402 public void connect AntiClockwiseFrom ( final Edge referenceEdge , final Edge 
orderingEdge ) { 

if ( orderingEdge = null ) throw new 

Illegal ArgumentException ( "Edge being ordered cannot be null." ); 
if ( ! orderingEdge . contains ( this ) ) throw new 

Illegal ArgumentException ( "Edge " + toStringQ + ":" + orderingEdge + " 
being ordered does not connect to this vertex." ); 
if ( orderingEdge . isOrdered About ( this ) ) throw new 

Illegal ArgumentException ( "Edge " + toStringQ + ":" + orderingEdge + " 
being ordered has already been ordered. " + referenceEdge ); 
if ( referenceEdge = null ) throw new 

Illegal ArgumentException ( "Edge used to determine order position cannot be 
null . " ) ; 

if ( ! referenceEdge . contains ( this ) ) throw new 

Illegal ArgumentException ( "Edge " + toStringQ + ":" + referenceEdge + " 
used to determine order position does not connect to this vertex." ); 
if ( ! referenceEdge . isOrdered About ( this ) ) throw new 

Illegal ArgumentException ( "Edge " + toStringQ + ":" + referenceEdge + " 
used to determine order position has not been ordered. " + orderingEdge ); 
if ( orderParentEdge = null ) throw new 

Illegal ArgumentException ( "Cannot order the given edge until both parent 
and stem edge have been set . " ) ; 

if ( orderStemEdge = null ) throw new 

IllegalArgumentException ( "Cannot order the given edge until the stem edge 
has been set . " ) ; 

411 referenceEdge . setOrder Anticlockwise ( this, orderingEdge ); 

412 } 

414 public LinkList <Edge> getCurrentlyOrderedEdges ( ) { 

415 final LinkList <Edge> orderedEdges = new LinkList <Edge>() ; 

416 if ( orderParentEdge != null ) { 

417 orderedEdges . addTail ( orderParentEdge ); 

4is Edge edge = orderParentEdge . getOrderClockwiseFrom ( this ): 

419 while ( edge != orderParentEdge ) { 

420 orderedEdges . addTail ( edge ) 

421 edge = edge . getOrderClockwiseFrom ( this ); 

422 } 

423 } 

424 return orderedEdges ; 

125 

427 /** 
128 

429 * ©return 

430 

431 public String toOrderedEdgesString ( ) { 

432 StringBuffer b = new S t r ingB uf f er ( ) ; 

433 b . append ( ' < 1 ) ; 

434 boolean first = true: 

435 for ( final Edge edge: get Current ly OrderedEdges ( ) ) { 

436 if ( first ) 

437 first = false 

438 else 

439 b . append ( " , " ) 

440 b.append( edge . getOtherEndFrom ( this ). toStringQ 

441 } 

442 b . append ( 1 > ' ) 
a:: return b. toStringQ 

444 
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446 /** 

447 * Returns the clockwise ordering of edges connected to this vertex , starting 

448 * from the parent edge . 

449 * ©return Edge [] — The array of ordered edges . 

450 * ©throws IllegalArgumentException If the parent edge is null or if the 
edges connected 

451 * to the vertex have not all been ordered. 

452 * / 

public Edge[] getEdgeOrder ( ) { 

if ( orderParentEdge = null ) throw new IllegalArgumentException ( 
"Vertex has not been ordered." ); 
455 final LinkList <Edge> orderedEdges = getCurrentlyOrderedEdges ( ) ; 

if ( orderedEdges . s i z e ( ) != size () ) throw new 

Illegal ArgumentException ( "Vertex (" + toStringQ + ") not fully ordered: 
" + orderedEdges ) ; 
457 final Edge[] ordered = new Edge [ size() ]; 

int i = 0; 

459 for ( final Edge e : orderedEdges ) 

460 ordered [H — h] = e; 

461 return ordered ; 



453 
454 



156 



162 



} 



464 public void orderOutboundEdge ( final Edge edge ) { 

465 if ( edge = null ) throw new Illegal ArgumentException ( 
"Outbound Edge cannot be null." ); 

if ( ! edge . contains ( this ) ) throw new IllegalArgumentException ( 
"Outbound Edge does not connect to this vertex." ); 

467 / * 

468 * Line below is valid except in the case where the parent 's frond is inbound 
to a vertex on parent 's stem. 

* if ( ! orderEdgeStack . isEmpty ( ) ) throw new Illegal ArgumentException ( "Edge 

Stack is not empty: " + edge + " — " + orderEdgeStack . to St ring ()) ; 

*/ 

473 if ( getSegment () . getChildEmbeddingDirection () = Segment .CLOCKWISE ) 

474 this . connect AntiClockwiseFrom ( orderParentEdge, edge ); 

475 else 

476 this . connectClockwiseFrom ( orderParentEdge, edge ); 

477 orderEdgeStack . addTail ( new OrderingEdgeBoundaries ( edge ) ); 

478 if ( Graph .DEBUG_ORDER ) System . out . println ( toString () + " : Order 
Outbound " + edge + " - " + ( get Segment (). get ChildEmbeddingDirect ion ( ) = 
Segment .CLOCKWISE? "AC" : "C" ) + " from " + orderParentEdge + " - " + 
toOrderedEdgesString ( ) ); 

} 



181 



public void orderlnboundEdge ( final Edge edge ) { 

482 if ( orderEdgeStack . isEmpty ( ) ) { 

483 if ( getSegment () . getChildEmbeddingDirection () = Segment . CLOCKWISE ) 

484 this . connectClockwiseFrom ( orderStemEdge , edge ); 

485 else 

486 this . connect AntiClockwiseFrom ( orderStemEdge, edge ); 

487 if ( Graph. DEBUG_ORDER ) System . out . println ( toStringQ + ": Order 
Inbound " + edge + " - " + ( getSegment ( ) . getChildEmbeddingDirection ( ) 
= Segment .CLOCKWISE? "C" : "AC" ) + " from " + orderStemEdge + " - 11 + 
toOrderedEdgesString ( ) ); 

488 } else { 

489 final OrderingEdgeBoundaries last = orderEdgeSt ack . get T ail ( ) ; 

490 final boolean direction = last . childEmbeddingDirection ; 

491 if ( orderEdgeStack . size () = 1 && 1 as t . edge . getDFSFrom ( ) = this ) { 

492 // Stack only has outbound edge on it . 

493 if ( direction = Segment .CLOCKWISE ) 

494 this . connectClockwiseFrom ( last, edge, edge ); 

495 else 



APPENDIX D. JAVA SOURCE CODE 326 



496 
•197 



498 
499 
500 
501 
.502 



503 
504 
505 



506 
507 
508 
509 
510 



} 



this . connect AntiClockwiseFrom ( last. edge, edge ); 
if ( Graph .DEBUG_ORDER ) System . out . println ( toString () + ": Order 
Inbound " + edge + " - " + ( 1 as t . childEmbeddingDirect ion = 
Segment . CLOCKWISE? " C ":" AC " ) + " from " + last, edge + " - " + 
toOrderedEdgesString ( ) ); 
} else { 

// Latest on stack is an inbound edge, 
if ( direction = Segment . CLOCKWISE ) { 

t his . connectClockwiseFrom ( last . antiClockwiseBoundary , edge ); 

if ( Graph .DEBUG_ORDER ) System . out . println ( toStringQ + ": 

Order Inbound " + edge + " - C from " + 

last . antiClockwiseBoundary + " - " + toOrderedEdgesString ( ) ); 
} else { 

this . connect AntiClockwiseFrom ( 1 a s t . clockwiseBoundary , edge ); 
if ( Graph. DEBUG_ORDER ) System . out . println ( toStringQ + ": 
Order Inbound " + edge + " - AC from " + last . clockwiseBoundary 
" - " + toOrderedEdgesString ( ) ); 

} 

} 

} 

orderEdgeStack . addTail ( new OrderingEdgeBoundaries ( edge ) ); 



512 public void orderRemoveEdge ( final Edge edge ) { 

513 if ( edge = null ) throw new IllegalArgumentException ( "Edge 
argument cannot be null . " ) ; 

if ( orderEdgeStack . isEmpty ( ) ) throw new IllegalArgumentException ( "Edge 
stack is empty: " + edge ); 

515 final OrderingEdgeBoundaries last = orderEdgeStack . removeTail () ; 

516 if ( last, edge != edge ) throw new IllegalArgumentException ( "Edge does 
not match last edge on stack: " + toString () + ", " + orderEdgeStack + " 
[" + last + " , " + edge + "] " ) ; 

} 



522 
523 
524 
525 
526 
527 
528 
529 
530 

531 
532 

533 
534 

535 
536 

537 
538 
539 
540 



public void setChildEmbeddingDirection ( final Edge edge, final boolean 

direction ) { 

if ( edge = null ) throw new IllegalArgumentException ( "Edge 

argument cannot be null . " ) ; 

if ( orderEdgeStack . isEmpty ( ) ) throw new IllegalArgumentException ( "Edge 
stack is empty. " + edge . to St ring ( ) ); 

final OrderingEdgeBoundaries last = orderEdgeStack . get Tail () ; 

/* 

* Deal with case when a cycle is added from an articulation vertex. 

* The outbound edge is added then the inbound edge is added to the same 

* vertex so , instead of matching the last edge , the penultimate edge 

* should match. 

*/ 

if ( last. edge != edge ) { 

final OrderingEdgeBoundaries penul = 
orderEdgeStack. getPenultimateTailQ ; 
if ( penul = null ) 

throw new IllegalArgumentException ( 

match last , and only , edge on stack 
if ( penul . edge != edge ) 

throw new IllegalArgumentException ( 



'Edge " + edge + " does not 
1 + orderEdgeStack ) ; 



'Edge 



■f edge + " does not 
match last or penultimate edge on stack " + orderEdgeStack ) ; 
if ( penul . edge . getDFSFrom ( ) != 1 as t . edge . getDFSTo ( ) ) 

throw new IllegalArgumentException ( "Edge " + edge + " - mismatch 
between penultimate and last edges on stack " + orderEdgeStack ); 
penul . childEmbeddingDirection = direction; 

} 

last . childEmbeddingDirection = direction ; 
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544 
545 
546 
547 
5 IS 

550 
551 
552 
553 
554 

556 
557 

558 
559 



private LinkList <OrderingEdgeBoundaries> orderEdgeStack = new 
LinkList <OrderingEdgeBoundaries >() ; 

private class OrderingEdgeBoundaries { 
private final Edge edge; 
private final Edge clockwiseBoundary ; 
private final Edge antiClockwiseBoundary; 

private boolean childEmbeddingDirection = Segment . CLOCKWISE; 

private OrderingEdgeBoundaries ( final Edge edge ) { 
this. edge = edge; 

clockwiseBoundary = Vertex . this . getClockwiseFrom ( edge ); 
antiClockwiseBoundary = Vertex . t his . get AntiClockwiseFrom ( edge ) 

} 



public String toStringQ { 

return "[" + clockwiseBoundary 
antiClockwiseBoundary + "]"; 

} 



edge 



D.3 Graph Type Files 



D.3.1 mgtaylor. graph. graphTypes.OrderedFaceTrisectionGraph 

package mgtaylor . graph . graphTypes ; 

import mgtaylor . graph . Graph ; 

import mgtaylor . graph . Vertex ; 

import mgtaylor . datastructures . LinkList ; 

import mgtaylor . datastructures . UnmodifiableLinkList ; 



15 
16 



19 
20 



import j ava . lang . Math ; 
import j ava . u t i 1 . Array List ; 

public class OrderedFaceTrisectionGraph extends Graph { 

public OrderedFaceTrisectionGraph ( int numberOfVertices ) { 
super ( numberOfVertices , 

Math . max( 3 * numberOfVertices —6, Math . max( numberOfVertices —1,0))) ; 
switch (numberOfVertices) { 
case 1: 

createVertex ( 0, "1" , 0) ; 
break ; 
case 2: 

createEdge( create Vertex ( 0, "1", 1 ), create Vertex ( 1, "2", 1 ) ): 
break ; 
default : 

final VertexHolder [ ] v = new VertexHolder [ numberOfVertices 

final ArrayList <EdgeHolder> e = new ArrayList <EdgeHolder >( 3* 
numberOfVertices — 6 ) ; 

final LinkList <FaceHolder> f = new LinkList <FaceHolder >() ; 
for ( int i = 0; i < numberOfVertices; i^+ ) 

v [ i ] = new VertexHolder ( i ) ; 
f . addTail ( new FaceHolder ( v[0], v[l], v[2] ) ); 
e.add( new EdgeHolder( v[0] , v[l] ) ) 
e.add( new EdgeHolder( v[0], v[2] ) ) 
e.add( new EdgeHolder( v[l], v[2] ) ) 



32 
33 
34 
35 
36 
37 
38 
39 

41 

42 
43 

45 
46 
17 

19 
50 
51 

53 
54 
55 

57 
58 

60 
61 
62 

64 
65 
66 
67 
68 
69 

71 
T2 
73 

74 
75 

77 
78 

80 
SI 
32 
33 
84 

86 

37 
S3 
89 
90 
91 
92 
93 
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for ( int i = 3; i < numberOfVertices ; ) 

f . addAHTail ( f . removeHead ( ) . sp li t F ace ( v[i], e)); 
for ( int i = 0; i < numberOfVertices; i^+ ) 

v[i ]. generateVertexQ ; 
for ( int i = 0; i < 3* numberOfVertices —6; i^+ ) 

e . get ( i ) . generateEdge () ; 

} 

} 

protected class VertexHolder { 
private final int index; 

private final UnmodifiableLinkList <EdgeHolder> edges = new 
UnmodifiableLinkList <EdgeHolder >() ; 

protected VertexHolder ( final int i ) { 

index = i ; 

} 

protected void connectEdge( final EdgeHolder edge ) { 
edges . addTail ( edge ); 

} 

protected void generateVertex ( ) { 

createVertex( index, Integer. toString( index + 1 ), edges. size() ); 

} 

protected int getlndexQ { return index; } 

} 

protected class EdgeHolder { 

private final VertexHolder from; 
private final VertexHolder to; 

protected EdgeHolder ( final VertexHolder f , final VertexHolder t ) { 
from = f ; 
to = t ; 

from . connectEdge ( this ); 
to . connectEdge ( this ); 

} 

protected void generateEdge ( ) { 

ArrayList<Vertex> vertices = get Vertices () ; 

createEdge( vertices. get( from .getlndexQ ), vertices. get( 
to . getlndex ( ) ) ) ; 

} 

} 

protected class FaceHolder { 

private final VertexHolder]] vertices = new VertexHolder [ 3 ] ; 

public FaceHolder ( VertexHolder vl , VertexHolder v2 , VertexHolder v3 ) { 
vertices [0] = vl; 
vertices [ 1 ] = v2 ; 
vertices [2] = v3; 

} 

protected LinkList <FaceHolder> splitFace ( final VertexHolder v, final 
ArrayList <EdgeHolder> e ) { 

for ( VertexHolder vertex: vertices ) 

e . add ( new EdgeHolder ( vertex, v ) ); 

final LinkList <FaceHolder> faces = new LinkList <FaceHolder >() ; 

faces . addTail ( new FaceHolder( vertices [0], vertices [1], v ) ); 

faces . addTail ( new FaceHolder( vertices [1], vertices [2], v ) ); 

faces . addTail ( new FaceHolder( vertices [2], vertices [0], v ) ); 

return faces ; 
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D.3.2 mgtaylor. graph. graphTypes.PlanarMultiWheelGraph 



i package mgtaylor . graph . graphTypes ; 

import java . util . ArrayList ; 

import mgtaylor . graph . Graph ; 
import mgtaylor . graph . Vertex ; 

/ * * 

* <p>A planar graph shaped like a wheel. By varying the number of spokes in the 

* graph the maximum degree of the vertices in the graph can be c o nt r oiled . </p> 

* <p>The graph is formed from a central vertex; emanating from this are a 

* number of spokes , each spoke formed of a straight line of vertices and 

* connecting edges formed into a regular radial pattern around the central 

* vertex ; and in the centre of each triangular region formed by pairs of 

* neighbouring spokes is a single (hub) vertex connected to each vertex in 

* both sets of spokes and the central vertex. If the graph is formed with an 

* outer ring of edges then the extreme vertex on each spoke is connected to 

* the corresponding vertex terminating the neighbouring spokes and forming a 

* ring around the graph. </p> 
* 

* <p>For a graph with v vertices and s spokes , there is:</p> 

* <ul> 

* <li>One central vertex , connected to 2s vertices (each of the s hub vertices 

* and the first vertex of each of the s spokes );</ 1 i > 

* <li >(v — s — 1) vertices forming the spokes; of these there are: 

* <ul> 

* <li;W vertices terminating each spoke, each is connected 3 vertices if there 

* is no outer ring of edges (the previous spoke vertex , or the centre vertex 

* if the spoke is a single vertex long, and the two adjacent hub vertices) or 

* 5 vertices if there is an outer ring;</li> 

* <li >(v — 2s — 1) vertices split evenly between s spokes , each is connected 

* to 4 vertices (the two adjacent hub vertices and the next and previous 

* vertex in the spoke)</li> 

* </ulx/li> 

* <li;Whub vertices , each is connected to 2(v — s — l)/s + 1 vertices (each 

* vertex in two spokes and the central vertex. </li> 

* </ul> 



* <p>A maximal planar graph will have (3v 

* with an outer ring has 



6) edges . A PlanarMultiWheelGraph 



( 2 s +&nbsp ; 5 s +&nbsp ; 4 ( v — &nbsp ; 2 s — &nbsp ; 1 )  +&nbsp ; s ( 2 ( 

* = (3v —  3 — &nbsp ; s ) edges. Therefore a PlanarMultiWheel graph 

* with 3 spokes will be maximal planar and as the number of spokes increases 

* there is a linear decrease in the number of edges compared to a maximal 

* planar graph. </p> 
* 

* ©author Martyn Taylor 

* 

*/ 

public class PlanarMultiWheelGraph extends Graph { 

private static final boolean SHOW_VERTEK_TYPE_IN_NAME = false; 

private final Vertex center ; 

private final ArrayList <Vertex> hubs; 

private final ArrayList <ArrayList <Vertex» spokes; 



/ — &nbs 
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/* * 

* <p>Creates a planar graph with the given number of vertices; the graph 

59 * is formed from a number of radial spokes and each pair of adjacent 

60 * spokes is connected by edges to a hub vertex forming a number of 

* wheels. </p> 
* 

63 * @param numberOfVertices 

64 * (Sparam numberOfSpokes 

* @param createOuterRing 

*/ 

public PlanarMultiWheelGraph ( final int numberOfVertices, final int 
numberOfSpokes , final boolean createOuterRing ) { 

* Number of Spokes is limited by (number of vertices — 1) /2. 

* Wheel graph is maximal planar with the exception of the outer face. 

* If there is an outer ring of edges connecting the vertices on the 

* extreme of the spokes then there are (numberOfSpokes — 3) edges 

* removed from a maximal planar graph; otherwise there is the outer 

* ring of edges missing as well then there are an additional 

* (numberOfSpokes) missing. 
*/ 

super ( numberOfVertices, 

78 3 * numberOfVertices — 3 

79 — ( createOuterRing ? 1 : 2 ) *Math . max( 3, Math.min( numberOfSpokes, 
getMaximumNumberOfSpokes ( numberOfVertices ) ) ) 

); 

si if ( numberOfVertices < 7 ) { 

82 center = null ; 

hubs = new ArrayList <Vertex >( ) ; 
spokes = new ArrayList <Array List <Vertex >>( ); 

85 return ; 

86 } 

final int wheels = Math.max( 3, Math.min( numberOfSpokes, 
getMaximumNumberOfSpokes ( numberOfVertices ) ) ) ; 

88 final int numberOfSpokeVertices = numberOfVertices — 1 — wheels ; 

89 final int baseSpokeLength = numberOfSpokeVertices / wheels ; 
final int additionalSpokes = numberOfSpokeVertices % wheels; 
center = create Vertex ( 0, (SHOW_VERTEX_TYPE_lN_NAME? " C 1 " : " 1 " ) , wheels * 

2 ); 

92 hubs = new ArrayList <Vertex >( wheels ); 

93 spokes = new ArrayList <Array List <Vertex>>( wheels ); 

int count = 2; 

96 for ( int i = 0; i < wheels ; i^+ ) { 

97 final int spokeLength = baseSpokeLength + (additionalSpokes > i?l:0) ; 
final int nextSpokeLength = baseSpokeLength + (additionalSpokes > ((i + 
wheels - 1) % wheels )? 1 : 0) ; 

Vertex hub = createVertex ( count - 1, (SHOW_VERTEX_TYPE_lN_NAME? " H " : " " ) 
+ Integer . toString ( count ), spokeLength + nextSpokeLength + 1 ); 

100 countH — h; 

101 hubs, add ( hub ); 

102 createEdge( center , hub ) ; 

103 final ArrayList <Vertex> spoke = new ArrayList <Vertex >( spokeLength ); 

104 spokes, add ( spoke ); 

105 Vertex previous = center ; 

106 for ( int s = 0; s < spokeLength; s-H- ) { 

107 Vertex v = create Vertex ( count — 1, 
(SHOW_VERTEX_TYPE_IN_NAME? " S " : " " ) + Integer . toString ( count ), 3 + ( 
s < spokeLength — 1?1:( createOuterRing ? 2 : ) ) ); 

108 countH — h; 

109 spoke, add ( v ); 

no createEdge ( previous , v ) ; 

in createEdge ( hub , v ) ; 

112 previous = v; 
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113 } 

114 } 

115 ArrayList <Vertex> prevSpoke = spokes . get ( spokes . size ( ) — 1 ); 
lie for ( int i = 0; i < wheels ; ) { 

ii7 final ArrayList <Vertex> spoke = spokes . get ( i ); 

us final Vertex hub = hubs . get ( (i + 1) % wheels ); 

us for ( Vertex v: spoke ) 

120 createEdge ( hub , v ) ; 

121 if ( createOuterRing ) 

122 createEdge ( spoke . get ( spoke . size () — 1) , prevSpoke . get ( 
prevSpoke. size() — 1 ) ); 

123 prevSpoke = spoke ; 

124 } 



J l>r> 



} 



127 /*i 

128 * Returns the central vertex of the graph. 

129 * ©return Vertex 

130 

131 public Vertex getCenterVertex ( ) { 

132 return center 
j "■■> } 

135 /** 

136 * Returns the hub vertices 

137 * ©return 

138 * / 

139 public ArrayList <Vertex> getHubs() { 

140 return hubs ; 
j . i } 

143 /** 

144 * Returns the spokes of the graph. 

145 * ©return 

146 

147 public ArrayList <ArrayList <Vertex» getSpokesQ { 

148 return spokes ; 

149 } 

151 /** 

152 * Calculates the maximum number of spokes for the griven number of 

153 * vertices 

154 * Oparam numberOfVertices 

155 * ©return int 

156 * / 

157 public static int getMaximumNumberOfSpokes ( final int numberOfVertices ) { 

158 return (numberOfVertices — 1) / 2; 

159 } 
160 



D.3.3 mgtaylor. graph. graphTypes. Planar WheelGraph 



package mgtaylor . graph . graphTypes ; 

import java . util . ArrayList ; 

import mgtaylor . graph . Graph ; 
import mgtaylor . graph . Vertex ; 

public class PlanarWheelGraph extends Graph { 
private final Vertex innerHub ; 
private final Vertex outerHub ; 
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private final ArrayList <Vertex> rimVertices ; 

public PlanarWheelGraph ( final int numberOfVertices ) { 

super( numberOfVertices, (numberOfVertices < 2 ? :( number OfVertices = 
2?1:3 * numberOfVertices —6)) ); 

final int numberOfRimVertices = numberOfVertices > 4? numberOfVertices — 2: 
Math.min( numberOfVertices, 3 ); 

rimVertices = new ArrayList <Vertex >( numberOfRimVertices ); 

for ( int i = 1; i <= numberOfRimVertices; i++ ) 

rimVertices . add ( createVertex ( i — 1, Integer. toString( i ), 4 ) ); 
for ( int i = 1; i < numberOfRimVertices; i^+ ) 

createEdge( rimVertices. get( i — 1 ), rimVertices. get( i ) ); 
outerHub = numberOfVertices > 4? create Vertex ( numberOfVertices — 2, 
Integer . toString ( numberOfVertices — 1 ), numberOfVertices — 1 ) : null ; 
innerHub = numberOfVertices > 3? create Vertex ( numberOfVertices — 1, 
Integer . toString ( numberOfVertices ), numberOfVertices — 1 ) : null ; 
if ( innerHub != null ) 

for ( int i = 0; i < numberOfRimVertices; i++ ) 
createEdge ( innerHub, rimVertices . get ( i ) ); 
if ( outerHub != null ) 

for ( int i = 0; i < numberOfRimVertices; i++ ) 
createEdge ( outerHub, rimVertices . get ( i ) ); 
if ( numberOfRimVertices > 2 ) 

createEdge ( rimVertices . get ( ), rimVertices . get ( numberOfRimVertices 

- i ) ); 

} 

public Vertex getlnnerHubVertex ( ) { return innerHub; } 

public Vertex getOuterHub Vertex ( ) { return outerHub; } 

public Array List <Vertex> getRimVertices ( ) { return rimVertices; } 



D.3.4 mgtaylor. graph. graphTypes.PermutableFlippableGraph 



i package mgtaylor . graph . graphTypes ; 



import mgtaylor . 
import mgtaylor . 



;raph . Vertex ; 
jraph . Graph ; 



public class PermutableFlippableGraph extends Graph { 

public PermutableFlippableGraph ( final int facets ) { 
super ( 3 + 2*(facets <l?l:facets) , 2 
final int f = ( facets <1?1: facets ) ; 



} 



5* ( f ace t s < 1?1 : f ace t s ) ) 



final Vertex vO 
final Vertex vl 
final Vertex v2 
createEdge ( vO , 
createEdge ( v2 , 
Vertex v = null 
for ( int i = 3 
final Vertex 
createEdge ( 



= createVertex ( 0, "1", 2 ); 

= createVertex ( 1, "2", 2*f + 1 

= createVertex ( 2, "3", 2* f + 1 



) 



createEdge ( 
if ( i % 2 = 

createEdge( 
v = vn ; 



vl ); 
vO ) ; 

i < 3 + 2* f ; l 
vn = create Vertex ( 
vl , vn ) ; 
v2 , vn ) ; 
) 

j vn ) ; 



++ ) { 



i, Integer. toString ( i + 1 ), 3 ) 



public static void main( String [] args ) { 

Graph g = new PermutableFlippableGraph ( 200 ) 
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System . out . println ( 
System . out . println ( 



toString() ); 
getVertices () . size () 



+ g • getEdges () . size () ) ; 



D.3.5 mgtaylor. graph. graphTypes.RandomMaximalPlanarGraphGenerator 



package mgtaylor . graph . graphTypes ; 

import java . util . ArrayList ; 

import mgtaylor . datastructures . LinkList ; 
import mgtaylor . graph . Edge ; 
import mgtaylor . graph . Graph ; 
import mgtaylor . graph . Vertex ; 

public class RandomMaximalPlanarGraphGenerator { 
private VertexHolder [ ] vhs ; 
private EdgeHolder[] ehs ; 

public RandomMaximalPlanarGraphGenerator ( final int size ) { 
if ( size<3 ) 

throw new Illegal ArgumentException ( "Size must be at least 3." ); 
vhs = new VertexHolder [ size ]; 
is ehs = new EdgeHolder [ 3 * size — 6 J; 

19 final ArrayList <VertexHolder [] > fhs = new Array List <VertexHolder []> ( 2 * 

size — 5 ) ; 

for ( int i = 0; i < size ; i++ ) 

vhs [ i ] = new VertexHolder ( i ); 
for (int i = 0; i < 3; i++) 

ehs [ i ] = new EdgeHolder ( vhs [ i ] , vhs [ ( i +1) %3] ) ; 
fhs.add( new VertexHolder [ ] { vhs [0] , vhs[l], vhs [2] } ); 

for ( int i = 3; i < size ; i++ ) { 

int facelndex = Math . min (( int ) Math . floor (Math . random ( ) * (2 * i — 5)), 
2 * i - 6) ; 

VertexHolder]] face = fhs . get ( facelndex ) ; 

fhs . set ( facelndex , new VertexHolder[]{ face [0] , face [ 1 ] , vhs [ i ] } ) ; 
fhs . add ( new VertexHolder[]{ f ace [ 1 ] , face[2], vhs[i] } ); 
fhs . add ( new VertexHolder[]{ f ace [ 2 ] , f ace [ ] , vhs [ i ] } ); 
for (int j = 0; j < 3; j++) 

ehs [3 * i — 6 + j ] = new EdgeHolder ( face [ j ] , vhs [ i ] ) ; 

} 



32 
33 



19 
50 



} 



public Graph generateGraph ( final int size ) { 
if ( size<3 ) 

throw new Illegal ArgumentException ( "Size must be at least 3. 
return new RandomMaximalPlanarGraph ( size ); 

} 



); 



private class RandomMaximalPlanarGraph extends Graph { 
private RandomMaximalPlanarGraph ( int size ) { 
super( size , 3 * size — 6 ) ; 
for ( int i = 0; i < size ; i^+ ) 

this . getVertices () . add ( vhs [i].generateVertex( this, size ) ) 
for ( int i = 0; i < 3 * size — 6; i++ ) 

this . getEdges () . add ( ehs[i].generateEdge( this, i ) ); 

} 

} 
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private class VertexHolder { 
private final int index; 

private final LinkList <EdgeHolder> edges = new LinkList <EdgeHolder >() : 

private VertexHolder ( final int index ) { 
this . index = index; 

} 

private void connectEdge( final EdgeHolder edge ) { 
edges . addTail ( edge ); 

} 

private Vertex generateVertex ( final Graph graph, int size ) { 
int e = 0; 

for (EdgeHolder eh: edges) 

if ( eh . from . index < size &fe eh . to . index < size ) 
e++; 

return new Vertex( graph, index, Integer . toString ( index +1), e ); 

} 



} 



private int getlndexQ { return index; } 



private class EdgeHolder { 

private final VertexHolder from; 
private final VertexHolder to; 

private EdgeHolder( final VertexHolder f, final VertexHolder t ) { 

from = f ; 
to = t ; 

from . connectEdge ( this ); 
to . connectEdge ( this ); 

} 

public Edge generateEdge ( final Graph graph, final int index ) { 

final java.util. Array List < Vert ex > vertices = graph. getVertices(); 
return new Edge ( graph , vertices. get( from .getlndexQ ), vertices. get( 
to.getlndexQ ), index ); 

} 

} 

public static void main( String [] args ) { 

RandomMaximalPlanarGraphGenerator gg = new 
RandomMaximalPlanarGraphGenerator ( 10 ); 
for ( int i = 3; i <= 10; i-H- ) 

System . out . pr i nt 1 n ( gg . generateGraph ( i ).toString() ); 

} 



D.3.6 mgtaylor. graph. graphTypes.ReduceableGraphGenerator 



i package mgtaylor . graph . graphTypes ; 

import mgtaylor . datastructures . LinkList : 

import mgtaylor . graph . Graph ; 

import mgtaylor . graph . Vertex ; 

import mgtaylor . graph . Edge ; 

public class ReduceableGraphGenerator { 
private final Vertex root ; 
private final int[] removableEdges ; 
private final VertexHolder]] v; 



12 

11 
15 
16 
17 
18 

20 
21 

23 
24 
25 

26 
27 
28 

30 
31 
32 
33 
34 
35 

37 

38 
39 

41 
42 
43 
44 
45 
46 
47 
48 
49 
50 

52 
53 
54 

56 
57 

59 

61 
62 
63 
64 
65 
66 
67 
68 
69 
70 
71 

73 
74 
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private final EdgeHolder[] e; 

public ReduceableGraphGenerator ( final Graph graph, final Vertex root ) { 
this . root = root ; 
graph ,DFS( root ) ; 

v = new VertexHolder [ graph . vert exS ize ( ) ]; 
e = new EdgeHolder [ graph . edge Size ( ) ]; 

for ( final Vertex vertex: graph . get Vert ices () ) 

v[vertex.getlndex()] = new VertexHolder ( vertex. getlndexQ, 
vertex . toString ( ) ); 

int r = 0; 

for ( final Edge edge: graph . getEdges ( ) ) { 

e[ edge.getlndexQ ] = new EdgeHolder( v[ edge, get From () .getlndexQ ] , 
v [ edge . getTo () . getlndex () ] ) ; 
if ( edge . isDFSFrond () ) 

r++; 

} 

removableEdges = new int[r]; 

r = 0; 

for ( final Edge edge: graph . getEdges ( ) ) 
if ( edge . isDFSFrond () ) 

removableEdges [ r++] = edge . getlndex () ; 



public int numberOfRemovableEdges ( ) { 
return removableEdges . lengt h ; 

} 

public Graph generateGraph ( final int NumberOfRemovedEdges ) { 
int nre ; 

if ( NumberOfRemovedEdges < ) 
nre = 0; 

else if ( NumberOfRemovedEdges > removableEdges . length ) 

nre = removableEdges . length ; 
else 

nre = NumberOfRemovedEdges ; 
return new ReduceableGraph ( nre ); 

} 

private class ReduceableGraph extends Graph { 

private ReduceableGraph ( final int NumberOfRemovedEdges ) { 
super ( v. length , NumberOfRemovedEdges ) ; 

for ( VertexHolder vh : v ) 

this . getVertices () . add ( vh .generateVertex( this ) ); 

this . setDFSRoot ( this . get Vertices (). get ( root . getlndex ( ) ) ); 

int i = 0; 
int r = 0; 

for ( EdgeHolder eh : e ) { 

if ( r < NumberOfRemovedEdges &fe removableEdges [ r ] = i ) 

r++; 
else 

this . edges . add ( eh . generateEdge ( this, i — r ) ); 

i++; 

} 

} 

} 

protected class VertexHolder { 
private final String text ; 
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private final int index; 

private final LinkList <EdgeHolder> edges = new LinkList <EdgeHolder > () : 

78 protected VertexHolder ( final int index, final String text ) { 

79 this . index = index; 
this . text = text ; 

} 

protected void connectEdge( final EdgeHolder edge ) { 
edges . addTail ( edge ); 

} 

protected void disconnect Edge ( final EdgeHolder edge ) { 
edges . remove ( edge ); 

} 

protected Vertex generate Vertex ( final Graph graph ) { 

return new Vertex ( graph, index, text, edges. size () ); 

} 



112 
113 



116 



134 
135 



} 



protected int getlndexQ { return index; } 



98 protected class EdgeHolder { 

99 private final VertexHolder from; 
ioo private final VertexHolder to; 

102 protected EdgeHolder ( final VertexHolder f , final VertexHolder t ) { 

103 from = f ; 

104 to = t ; 

105 from . connectEdge ( this ); 
loe to . connectEdge ( this ); 

107 } 

109 protected Edge generateEdge ( final Graph graph, final int index ) { 

no final j a va . u t i 1 . Array List <Vertex> vertices = graph . get Vert ices () ; 

in return new Edge ( graph , vertices. get( from .getlndexQ ), vertices. get( 
to.getlndexQ ), index ); 

} 



} 



115 public static void main( final String [] args ) throws Exception { 



final int size = 50; 
117 int count = 0; 

us while ( true ) { 

no final RandomMaximalPlanarGraphGenerator rg = new 

RandomMaximalPlanarGraphGenerator ( size ); 

120 final Graph gr = rg . generateGraph ( size ); 

121 final ReduceableGraphGenerator gg = new ReduceableGraphGenerator ( gr 
gr . get Vert ices (). get ( ) ); 

122 for ( int i = 0; i < gg . numberOfRemovableEdges ( ) ; i^+ ) { 

123 final Graph g = gg . generateGraph ( i ); 

124 try { 

125 g . s ile nt P lanar it y Tes t ( ) ; 

126 if ( ! g . isP lanar ( ) ) { 

127 System . out . println ( g.toStringQ ); 

128 return ; 

129 } 

} catch ( Exception e ) { 

131 System . out . println ( g.toStringQ ); 

132 throw e ; 

133 } 
} 

countH — h; 

136 if ( count % 10000 = ) 
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137 
138 
139 
140 
141 



System . out . println ( count ); 



//*/ 
/* 



1 19 
150 
151 
152 
153 
154 

165 
156 
157 



inal String [] graphs = { 

"nodes { 0, 1, 2, 3, 4, 5, 6, 7, 
17, 18, 19 }\nedges\n{\n(0 , 1), 
6) , (6 , 7) , (3 , 8) , (7 , 9) , (8 , 
12) , (8 , 13) , (2 , 13) , (10 , 13) , 
(1, 15) , (12, 15) , (3, 16) 
17) , (3 , 18) , (0 , 18) , (16 
"nodes { 0, 1, 2, 3, 4, 5, 
17, 18, 19 }\nedges\n{\n(0 
(4, 7) , (5, 8) , (1, 9) 
(2 , 11) , (6 , 11) , (10 



6) , 
10) 
13) 
15) 
17) 



(4 , 13) , (6 , 13) , (6 

(11, 15), (4, 16), (10, 16), (14, 16), (1 
(3, 18), (4, 18), (13, 18), (6, 19), (10, 



8, 9, 10, 11, 12, 13, 14, 15, 16, 
(1 , 2) , (2 , 3) , (3 , 4) , (3 , 5) , (5 , 
10) , (8 , 11) , (5 , 12) , (1 , 12) , (6 , 
(7 , 14) , (2 , 14) , (9 , 14) , (5 , 15) 
16) , (4, 16) , (2, 17) , (5, 17) , (6, 
(12 , 19) , (5 , 19) , (15 , 19)\n}" , 
8, 9, 10, 11, 12, 13, 14, 15, 16, 

I) , (1, 2) , (2, 3) , (3, 4) , (3, 5) , (4, 
(2, 9) , (7, 9) , (4, 10) , (2, 10) , (6, 

II) , (10 , 12) , (2 , 12) , (11 , 12) , (3 , 
14) , (4 , 14) , (10 , 14) , (6 , 15) , (10 , 

17) , (3, 17) , (5, 



(0, 
18) 



(i 



19) , (15 , 19)\n}' 



"nodes { 0, 1, 2, 3, 4, 



6 , 7 , 



17, 18, 19 }\nedges\n{\n(0 , 1), (1, 2), (2, 3), (3, 4) 
6), (4, 6), (2, 7), (4, 7), (6, 7), (4, 8), (1, 8) 
(0, 9), (5, 9), (5, 10), (3, 10), (9, 10), (3, 11) 



11) , (6 , 12) , (4 , 12) , (8 , 12) , (9 
14) , (3 , 14) , (4 , 14) , (8 , 15) , (6 
(7 , 16) , (1 , 17) , (6 , 17) , (8 , 17) 
19) , (0 , 19) , (9 , 19)\n}" , 
"nodes {0, 1, 2, 3, 4, 5, 6, 7, 8 
17, 18, 19 }\nedges\n{\n(0 , 1), 
6) , (3, 7) , (4, 8) , (8, 9) , (6, 
(12 , 14) , (7 , 15) , (13 , 16) , (7 
(19 , 0) , (11 , 19) \n}" , 
"nodes {0, 1, 2, 3, 4, 5, 6, 7 
17, 18, 19 }\nedges\n{\n(0 , 1) 
6) , (4 , 7) , (6 , 8) , (9 , 2) , (7 
0) , (11 , 1) , (3 , 11) , (12 , 2) , 
(7 , 13) , (14 , 6) , (14 , 5) , (10 
(16 , 2) , (16 , 7) , (9 , 16) , (17 
2) , (9 , 18) , (19 , 10) , (19 , 6) 
"nodes { 0, 1, 2, 3, 4, 5, 6, 
17, 18, 19 }\nedges\n{\n(0 , 1) 
6) , (4 , 7) , (7 , 8) , (8 , 9) , (8 
14) , (6 , 15) , (7 , 16) , (13 , 17) 
8) , (10 , 19)\n}" , 
"nodes { 0, 1, 2, 3, 4, 5, 
17, 18, 19 }\nedges\n{\n(0 



9, 10, 11, 12, 13, 14, 15, 16, 



13) , (10 , 13) 
15) , (12 , 15) 



(3 , 18) , (4 , 18) 



(3, 5) , (2, 
(6, 8) , (3, 9) , 
(9 , 11) , (10 , 
, 13), (2, 

16) , (6 , 16) 
(14, 18) , (3, 



(11 

(4, 



9, 10, 11, 12, 13, 14, 15, 16, 
2) , (2, 3) , (3, 4) , (3, 5) , (4 
, (6 , 11) , (10 , 12) , (9 , 13) , 



(1 
10) 

17) , (18 , 3) , (10 , 18) , (19 , 3) , 

, 8, 9, 10, 11, 12, 13, 14, 15, 16, 

(1, 2) , (2, 3) , (3, 4) , (4, 5) , (5 

9) , (10 , 6) , (10 , 5) , (8 , 10) , (11 

(12 , 4) , (5 , 12) , (13 , 2) , (13 , 3) , 



14) , (15 , 1) , (15 , 3) 
2) , (17 , 7) , (16 , 17) 
(14, 19)\n}", 
, 8, 9, 10, 11, 12, 13, 14, 15, 16 
(1, 2) , (2, 3) , (3, 4) 
10) , (6 , 11) , (7 , 12) , 



(11, 15) , 
(18 , 4) , (18 . 



(4, 5), (3 
(6 , 13) , (5 



(18 , 1) , (15 , 18) , (19 , 7) , (19 , 



6) , (5, 7) , (4, 8) , (8, 9) 



6 , 7 . 

1) , 
(7. 



8, 9, 10, 11, 12, 13, 14, 15, 16, 
(1 , 2) , (2 , 3) , (3 , 4) , (3 , 5) , (5 
10) , (8 , 11) , (11 , 12) , (9 , 13) , 
(14, 11), (14, 3), (12, 14), (15, 2), (15, 0), (3, 15), (16, 3), 
(16, 2), (15, 16), (17, 12), (17, 11), (14, 17), (18, 5), (18, 3), 

12) , (14, 19)\n}" , 



(10 , 18) , (19 , 3) , (19 . 



" nodes { , 1 



3, 4, 5, 6, 7, 



17, 18, 19 }\nedges\n{\n(0 
6) , (5 , 7) , (3 , 8) , (6 , 9) 



1) 

(5 



0), (5, 
(15, 3) 



12), (13 
(15, 5) 



2) , (13 
(7, 15) 



(1. 

10) 

0), (12, 
(16, 2) , 



9, 10, 11, 12, 13, 
2) , (2 , 3) , (3 , 4) 



14, 15, 16, 



(3, 5) 



0) , (7, 17) , (18 
19)\n}" 



(11, 2) , (4, 11) . 

13) , (14 , 0) , (14 . 

(16 , 0) , (13 , 16) , 

4) , (18, 1) , (11 , 18) , (19, 1) , (19, 3) 



(12: 
5) , 
(17, 



2) 
(12. 

5) 



(4, 
(12. 
14) 
(17. 



}; 

final Graph g = new Graph( graphs [ graphs . length — 1] ); 
g . setDFSRoot ( g . get Vertices (). get (0) ); 
g.DFSQ ; 

for ( final Vertex v : g . get Vertices ( ) ) { 

System . out . println ( v + "\t(" + v . getDFSIndex ( ) + ")\t" 
v. getLowPointl () + ",\t" + v . getLowPoint2 ( ) ); 



fo 



generateSegments ( ) ; 

r ( mgtaylor . graph . Segment s 



g . getSegments ( ) ) { 
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159 
160 
161 
162 
163 
164 
165 
166 
107 
168 



//* 



s . setDepthFromParent ( ) ; 

for (int i = 0; i < s . getDepth ( ) ; i++ 

System . out . print ( " " ) ; 
System . out . print ( s.toStringQ ); 
System . out . print ( " , " ) ; 
System .out.println( s. get LeafVer tex ( ) 



) 



} 

g . embedSegments ( ) ; 

g . generateEdgeSides ( ) ; 

System . out . print In ( g. toVertexCyclicOrderString () 



D.3.7 mgtaylor. graph. graphTypes.ReduceableBiconnectedGraphGenerator 



package mgtaylor . graph . graphTypes ; 

import mgtaylor . datastructures . LinkList ; 
import mgtaylor . graph . Graph ; 
import mgtaylor . graph . Vertex ; 
import mgtaylor . graph . Edge ; 
import mgtaylor . graph . Segment ; 

public class ReduceableBiconnectedGraphGenerator { 
private final Vertex root ; 
private final int[] removableEdges ; 
private final VertexHolder [ ] v; 
private final EdgeHolder[] e; 

public ReduceableBiconnectedGraphGenerator ( final Graph graph, final Vertex 
root ) { 
is this . root = root ; 

17 graph . DFS( root ) ; 

graph . generateSegments () ; 

v = new VertexHolder [ graph . vert exS ize ( ) ]; 
e = new EdgeHolder [ graph . edgeSize ( ) ]; 



for 



for 



( final Vertex vertex: graph . get Vertices () ) 
v [ vertex . getlndex () ] = new VertexHolder ( vertex . getlndex ( ) 
vertex . toString ( ) ); 



( final Edge edge: graph . getEdges ( ) ) 
e[ edge . getlndex ( ) ] = new EdgeHolder ( 
v [ edge . get To ().getlndex() ] ); 



edge . getFrom () . getlndex () 



30 
31 



33 
31 



38 
39 



// 



int r = 0; 

for ( final Segment segment: graph . getSegments ( ) ) { 
if ( segment . get Edges (). s i z e ( ) = 1 ) { 

System . out . p r i nt In ( segment + ", " + 
segment . getEdges () . getTail () . getlndex () ) ; 
r++; 

} 

} 



removableEdges = new int[r]; 

r = 0; 

for ( final Segment segment: graph . getSegments ( ) ) { 
if ( segment . get Edges (). s i z e ( ) = 1 ) { 

removableEdges[r] = segment. getEdges().getTail().getIndex(); 

System . out . print ( removableEdges [ r ] + ", " ); 



// 



13 
44 
45 

47 
-18 

50 
51 
52 

54 
55 
56 
57 
58 
59 
60 
61 
62 
63 

65 
66 
67 

69 
70 

72 

74 
75 
76 
77 
78 
79 
SO 
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82 
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84 

86 
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88 
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92 
93 
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} 

} 

java . util . Arrays . sort ( removableEdges ) ; 

// System . out . println ( ( removableEdges . lengt h = r )); 
} 

public int numberOfRemovableEdges ( ) { 
return removableEdges . length ; 

} 

public Graph generateGraph ( final int NumberOfRemovedEdges ) { 
int nre ; 

if ( NumberOfRemovedEdges < ) 
nre = 0; 

else if ( NumberOfRemovedEdges > numberOfRemovableEdges ( ) ) 

nre = numberOfRemovableEdges ( ) ; 
else 

nre = NumberOfRemovedEdges ; 
return new ReduceableGraph ( nre ); 



private class ReduceableGraph extends Graph { 

private ReduceableGraph ( final int NumberOfRemovedEdges ) { 
super ( v. length , NumberOfRemovedEdges ); 

for ( VertexHolder vh : v ) 

this . getVertices () . add ( vh . generateVertex ( this ) ); 

this . setDFSRoot ( this . get Vertices (). get ( root . getlndex ( ) ) ); 

int i = 0; 
int r = 0; 

for ( EdgeHolder eh : e ) { 

if ( r < NumberOfRemovedEdges &fe removableEdges [ r ] = i ) 

r++; 
else 

this . edges . add ( eh . generateEdge ( this, i — r ) ); 

i++; 

} 

} 

} 

protected class VertexHolder { 
private final String text ; 
private final int index; 

private final LinkList <EdgeHolder> edges = new LinkList <EdgeHolder > () ; 

protected VertexHolder ( final int index, final String text ) { 
this . index = index; 
this . text = text ; 

} 

protected void connectEdge( final EdgeHolder edge ) { 
edges . addTail ( edge ) ; 

} 

protected void disconnect Edge ( final EdgeHolder edge ) { 
edges . remove ( edge ); 

} 

protected Vertex generate Vertex ( final Graph graph ) { 

return new Vertex ( graph, index, text, edges. size () ); 

} 
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109 

111 
1112 
113 

115 
116 
117 
118 
119 
120 

122 
123 
124 

125 
126 

128 
129 
130 
131 
132 
133 
134 

135 
136 



} 



protected int getlndexQ { return index; } 



final VertexHolder t ) { 



protected class EdgeHolder { 

private final VertexHolder from; 
private final VertexHolder to; 

protected EdgeHolder ( final VertexHolder 
from = f ; 
to = t ; 

from . connectEdge ( this ); 
to . connectEdge ( this ); 

} 

protected Edge generateEdge ( final Graph graph, final int index ) { 
final java . util . ArrayList <Vertex> vertices = graph. getVertices(); 
return new Edge ( graph , vertices. get( from .getlndexQ ), vertices. get( 
to.getlndexQ ), index ); 



} 



} 



args ) throws Exception { 



public static void main( final String 
final int size = 15000; 
final Graph gr ; 
switch ( 3 ) { 

case 2: gr = new TriangularPrismMaximalPlanarGraph ( 

gr = new OrderedFaceTrisectionGraph ( size ) 
gr = new RandomMaximalPlanarGraphGenerator ( 
) . generateGraph ( size ); break; 
default: gr = new PlanarMultiWheelGraph ( size 
} 



case 
case 



size ) ; 
break ; 



break ; 



3 , true ) ; break ; 



139 
140 
141 
142 
143 
144 
145 
146 



147 
148 
149 
150 
151 
152 

153 
154 

155 
156 
157 
158 
159 
160 
161 
162 
163 
164 



// 
// 



//*/ 
/* 



final ReduceableBiconnectedGraphGenerator gg = new 
ReduceableBiconnectedGraphGenerator ( gr , gr . getVertices () . get (0) 
final Graph g = gg . generateGraph ( gg . numberOfRemovableEdges ( ) ) 
System . out . println ( g.toStringQ ); 

for ( int i = 0; i < gg . numberOfRemovableEdges ( ) ; i += 100 ) { 



); 



final Graph g = gg . generateGraph ( 
g.DFSQ ; 

g.generateSegmentsQ ; 
g . embedSegments ( ) ; 

System. out. println( g.edgeSize() + 
g.calculateAverageSegmentDepthQ -f 
"\t" + g . get Per mutations (). s i z e ( ) 



) 



■Yt" ^ 
"\t" 
- »\t" 



g . getNumberOfSegments ( ) 



} 



g. calculateNumberOfFlippableBlocks () ) 



final int size = 20; 
int count = 0; 
while ( true ) { 

final RandomMaximalPlanarGraphGenerator rg = new 

RandomMaximalPlanarGraphGenerator ( size ); 

final Graph gr = rg . generateGraph ( size ); 

final ReduceableGraphGenerator gg = new ReduceableGraphGenerator ( gr 
gr.getVertices().get(0) ); 

for ( int i = 0; i < gg . numberOfRemovableEdges ( ) ; i^+ ) { 
final Graph g = gg . generateGraph ( i ); 
try { 

g. silentPlanarityTest () ; 
if ( ! g . isPlanar ( ) ) { 

System . out . p r i n 1 1 n ( g.toStringQ ); 

return ; 

} 

} catch ( Exception e ) { 

System . out . println ( g.toStringQ ); 
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165 
166 
167 
168 
169 
170 
171 
172 
173 
174 



throw e ; 



} 



//*/ 
/* 



182 
183 
184 
185 
186 



} 

countH — h; 

if ( count % 100000 = ) 

System . out . println ( count ) 



fi 



n a 1 S t r i ng [ ] 
"nodes { 
17, 18, 
6), (6, 

12) , (8, 
(1, 15), 
17), (3, 
"nodes { 
17, 18, 
6), (4, 
10), (2, 

13) , (4, 
15) , (11 
17), (3, 
"nodes { 
17, 18, 
6), (4, 
(0, 9), 



11) 
14) 



(6 
(3 



graphs = { 
0, 1, 2, 3, 4, 5, 
19 }\nedges\n{\n(0 , 
7) , (3 , 8) , (7 , 9) , 
13) , (2 , 13) , (10 , 
(12 , 15) , (3 , 16) , 
18) , (0 , 18) , (16 , 
0, 1, 2, 3, 4, 5, 
19 }\nedges\n{\n(0 , 
7) , (5, 8) , (1, 9) , 

11) , (6 , 11) , (10 , 
13) , (6 , 13) , (6 , 

, 15) , (4 , 16) , (10 
18) , (4 , 18) , (13 , 
0, 1, 2, 3, 4, 5, 
19 }\nedges\n{\n(0 , 
6) , (2, 7) , (4, 7) , 
(5 , 9) , (5 , 10) , (3 

12) , (4 , 12) , (8 



fi 



(7, 16) , 
19), (0, 
"nodes { 
17, 18, 
6), (3, 
(12, 14) 
(19, 0) , 
"nodes { 
17, 18, 
6), (4, 
0), (11, 
(7, 13) , 
(16, 2) , 

2), (9, 
"nodes { 
17, 18, 
6), (4, 
14), (6, 
8) , (10, 
"nodes { 
17, 18, 
6), (5, 
(14, 11) 
(16, 2) , 
(10, 18) 
"nodes { 
17, 18, 
6), (5, 
0), (5, 
(15, 3) , 
0), (7, 
19)\n}" 

}; 

n a 1 Graph g 
setDFSRoot ( 
DFS ( ) ; 



14) , (4 
(1, 17) 
19) , (9 
, 1 , 2 



14), (8 
(6, 17) 
19)\n}" 
3, 4, 5 



6 , 7 , 

1) , 
(8, 
13) , 
(0, 
18) , 
6 , 7 , 

I) , 
(2, 

II) , 

14) , 
, 16) 

18) , 
6, 7, 8 

1), (1 
(6, 7) 
, 10), 
12) , (9 

15) , (6 
(8, 17) 



9, 10, 11, 12, 13, 14, 15, 16, 
(1 , 2) , (2 , 3) , (3 , 4) , (3 , 5) , (5 , 
10) , (8, 11) , (5, 12) , (1, 12) , (6, 
(7 , 14) , (2 , 14) , (9 , 14) , (5 , 15) 
16) , (4 , 16) , (2 , 17) , (5 , 17) , (6 , 
(12 , 19) , (5 , 19) , (15 , 19)\n}" , 
8, 9, 10, 11, 12, 13, 14, 15, 16, 
(1 , 2) , (2 , 3) , (3 , 4) , (3 , 5) , (4 , 
9) , (7 , 9) , (4 , 10) , (2 , 10) , (6 , 
(10 , 12) , (2 , 12) , (11 , 12) , (3 , 
(4 , 14) , (10 , 14) , (6 , 15) , (10 , 
, (14, 16) , (1, 17) , (3, 17) , (5, 
(6 , 19) , (10 , 19) , (15 , 19)\n}" , 
9, 10, 11, 12, 13, 14, 15, 16, 
2) , (2 , 3) , (3 , 4) , (3 , 5) , (2 , 
(4, 8) , (1, 8) , (6, 8) , (3, 9) , 
(9 , 10) , (3 , 11) , (9 , 11) , (10 , 
13) , (10 , 13) , (11 , 13) , (2 , 
15) , (12 , 15) , (4 , 16) , (6 , 16) 
(3 , 18) , (4 , 18) , (14 , 18) , (3 , 



19 }\nedges\n{\n(0 , 
7) , (4 , 8) , (8 , 9) , 
, (7 , 15) , (13 , 16) 
(11, 19)\n}", 
0, 1, 2, 3, 4, 5, 
19 }\nedges\n{\n(0 , 
7) , (6 , 8) , (9 , 2) , 
1) , (3, 11) , (12, 
(14 , 6) , (14 , 5) , 
(16 , 7) , (9 , 16) , 
18) , (19 , 10) , (19 , 

0, 1, 2, 3, 4, 5, 
19 }\nedges\n{\n(0 , 
7) , (7 , 8) , (8 , 9) , 
15) , (7 , 16) , (13 , 
19)W", 

0, 1, 2, 3, 4, 5, 
19 }\nedges\n{\n(0 , 
7) , (4 , 8) , (8 , 9) , 
, (14 , 3) , (12 , 14) 

(15 , 16) , (17 , 12) 
, (19 , 3) , (19 , 12) 

0, 1, 2, 3, 4, 5, 
19 }\nedges\n{\n(0 , 
7) , (3 , 8) , (6 , 9) , 
12) , (13 , 2) , (13 , 

(15 , 5) , (7 , 15) , 
17) , (18 , 4) , (18 , 



6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 
1) , (1, 2) , (2, 3) , (3, 4) , (3, 5) , (4 
(6 , 10) , (6 , 11) , (10 , 12) , (9 , 13) , 

, (7 , 17) , (18 , 3) , (10 , 18) , (19 , 3) , 



6 , 7 

1) 

(7 
2) , 
(10 
(17 

6) 
6 , 

1) 

(8 
17) 



, 8, 9, 10, 11, 12, 13, 14, 15, 16, 
(1, 2) , (2, 3) , (3, 4) , (4, 5) , (5, 

9) , (10 , 6) , (10 , 5) , (8 , 10) , (11 , 
(12 , 4) , (5 , 12) , (13 , 2) , (13 , 3) , 

14) , (15 , 1) , (15 , 3) , (11 , 15) , 
2) , (17 , 7) , (16 , 17) , (18 , 4) , (18 . 
(14, 19)\n}", 
, 8, 9, 10, 11, 12, 13, 14, 15, 16, 
(1, 2) , (2, 3) , (3, 4) , (4, 5) , (3, 

10) , (6, 11) , (7, 12) , (6, 13) , (5, 
, (18 , 1) , (15 , 18) , (19 , 7) , (19 , 



6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 
1) , (1, 2) , (2, 3) , (3, 4) , (3, 5) , (5, 
(7 , 10) , (8 , 11) , (11 , 12) , (9 , 13) , 

, (15 , 2) , (15 , 0) , (3 , 15) , (16 , 3) , 

, (17 , 11) , (14 , 17) , (18 , 5) , (18 , 3) , 

, (14, 19)\n}", 

6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 
1) , (1, 2) , (2, 3) , (3, 4) , (3, 5) , (4, 
(5 , 10) , (11 , 2) , (4 , 11) , (12 , 2) , (12 . 

0) , (12, 13), (14, 0), (14, 5), (12, 14) 
(16, 2), (16, 0), (13, 16), (17, 5), (17. 

1) , (11, 18) , (19, 1) , (19, 3) , (8, 



= new Graph( graphs [ graphs . length — 1] ); 
g . getVertices () . get (0) ); 



for ( final Vertex v 



;et Vertices ( ) ) { 
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192 
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194 
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202 
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//*/ 
} 

} 



System . out . println ( v + "\t(" + v . getDFSIndex ( ) + ")\t" 
v. getLowPointl () + ",\t" + v . getLowPoint2 ( ) ); 



g . getSegments ( ) ) { 

H- ) 



} 

g.generateSegmentsQ ; 
for ( mgtaylor . graph . Segment s 

s . setDepthFromParent ( ) ; 

for (int i = 0; i < s.getDepthQ 
System . out . print ( " " ) ; 

System . out . print ( s.toStringQ ); 

System . out . print ( " , " ) ; 

System . out . pr i nt 1 n ( s . getLeafVertex ( ) ); 

} 

g . embedSegments ( ) ; 

g . gener at eEdgeS ides ( ) ; 

System . out . println ( g . toVertexCyclicOrderString () ) 



D.3.8 mgtaylor. graph. graphTypes.TriangularPrismMaximalPlanarGraph 



package mgtaylor . graph . graphTypes ; 

import mgtaylor . graph . Graph ; 
import mgtaylor . graph . Vertex ; 

public class TriangularPrismMaximalPlanarGraph extends Graph { 

public TriangularPrismMaximalPlanarGraph ( final int numberOfVertices ) { 
super ( Math . max ( 3 , numberOfVertices), 3 * Math.max(3, numberOfVertices) 

); 

final int vertexSize = Math.max( 3, numberOfVertices ) ; 
final int extraVertices = vertexSize % 3; 

final Vertex [] vs = new Vertex [ vertexSize]; 
int i = 0; 

if ( extraVertices > ) { 

vs[i] = createVertex ( i, Integer. toString( i + 1 ), 3 ); 

} 

for ( int k = 0; k < 3; k++ ) { 

vs[i] = createVertex ( i, Integer. toString( i + 1 ), vertexSize > 
5? ( extraVertices > 0?5:4):(3 + extraVertices ) ); 
for ( int j = 0; j < i ; j++ ) 
createEdge( vs[j], vs[i] ); 

} 

for ( ; i < vertexSize — (extraVertices = 2?1:0) ; i += 3 ) { 

final int capacity = (i + 3) < vertexSize ?6 : (4 + (extraVertices = 
2?1:0)) ; 

vs[i] = createVertex ( i, Integer. toString( i + 1 ), capacity ); 
vs[i+l] = create Vertex ( i+1, Integer . toString ( i + 2 ), capacity ) 
vs[i+2] = createVertex ( i+2, Integer. toString ( i + 3 ) , capacity ) 



30 


createEdge ( 


vs [ 


], vs[ 


i + 


11 


); 




31 


createEdge ( 


vs [ 


]. vs[ 


i + 


2] 


); 




32 


createEdge ( 


vs [ 


+ 1], 


vs 


i + 


2] 


); 


33 


createEdge ( 


vs [ 


- 3], 


vs 


i] 


); 




34 


createEdge ( 


vs [ 


- 1], 


vs 


i] 


); 




35 


createEdge ( 


vs [ 


- 2] , 


vs 


i 4 


i] 


); 


36 


createEdge ( 


vs [ 


- 3], 


vs 


i + 


i] 


); 


37 


createEdge ( 


vs [ 


- 1], 


vs 


i + 


2] 


); 


38 


createEdge ( 


vs [ 


" 2] , 


vs 


i 4 


2] 


); 
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} 

if ( extraVertices = 2 ) { 

vs[i] = createVertex ( i, Integer. toString( i + 1 ), 3 ); 
for ( int j = i - 3; j < i ; j++ ) 
createEdge( vs[j], vs[i] ); 

} 
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D.4 Empirical Testing Files 



D.4.1 mgtaylor. graph. test. PlanaritySpeedTest Viewer 

r 

1 package mgtaylor . test ; 

import java . io . * ; 
import java. util .*; 

import javax . swing . * ; 

import mgtaylor . graph . * ; 

import mgtaylor . test . parsers . GraphExtractorLogParser ; 

public class PlanaritySpeedTest Viewer extends JFrame { 

private static final int graphRepetitions = 500; 

private static final int graphMinSize = 20; 

private static final int graphMaxSize = 5000; 

private static final int graphSizelncrement = 1; 

private static final int graphMinWheels = 3; 

private static final int graphMaxWheels = 3; 



private static final long serial VersionUID = -556303577105329510L ; 

public PlanaritySpeedTest Viewer ( ) { 
PrintStream writer = System . out ; 

for ( int wheels = graphMinWheels; wheels <= graphMaxWheels; wheels^+ ) { 
for ( int v = graphMaxSize; v >= graphMinSize; v — = graphSizelncrement 
) { 

Graph graph = new mgtaylor . graph . graphTypes . PlanarMultiWheelGraph ( 
v , wheels , true ) ; 

writer . print In ( graph . toString ( ) ); 
Random random = new Random ( ) ; 

Array List <Vertex> vertices = graph . get Vert ices () ; 
for ( int r = 1; r <= graphRepetitions; r^+ ) { 

int index = random . nextlnt ( v ); 

Vertex root = v e r t i c e s . get ( index ); 

graph . timePlanarityTest ( root , writer ) ; 

} 

graph = null ; 



} 

public static void speedTestGraphWithDifferentRoot ( final PrintStream out, 
final Graph g, final int repetitions ) { 

speedTestGraphWithDifferentRoot ( out, g, repetitions , 0, g . vert exS ize ( ) 

i ); 

} 

public static int getRootlndex ( int size , int numer , int denom ){ 
return Math, round ( numer * ( size — 1 ) / denom ) ; 

} 

public static void speedTestGraphWithDifferentRoot ( final PrintStream out, 
final Graph g, final int repetitions , final int start , final int end ) { 
if ( out != null ) out.println( g.toStringQ ); 
for ( int i = start ; i <= end; i++ ) { 

final Vertex root = g . get Vertices (). get ( i ); 
for ( int j = 0; j < repetitions; j++ ) 
g.timePlanarityTest( root, out ); 

} 
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} 

public static void speedTestGraphWithlncrementingWheels ( final PrintStream 
out , final int size , final int fromWheel , final int toWheel , final int 
wheellncrement , final int repetitions ) { 

for ( int i = fromWheel; i <= toWheel ; i += wheellncrement ) { 

final Graph g = new mgtaylor . graph . graphTypes . PlanarMultiWheelGraph ( 
size , i , true ) ; 
out.println( g.toStringQ ); 
for ( int r = 1; r <= repetitions; r++ ) 
g . timePlanarityTest ( out ); 

} 

} 

public static void speedTestSimilarTriangleGraphsWithlncreasingSizes ( final 
PrintStream out , final int from , final int to , final int increment , final int 
repetitions , final int numerator, final int denominator ) { 
for ( int i = from ; i <= to ; i += increment ) { 
final Graph g = new 

mgtaylor . graph . graphTypes . TriangularPrismMaximalPlanarGraph ( i ) ; 
out.println( g.toStringQ ); 

final ArrayList <Vertex> vertices = g . get Vert i ces () ; 
final Vertex root = vertices. get( get Root Index ( vertices, s i z e ( ) , 
numerator , denominator ) ) ; 
for ( int r = 0; r < repetitions; r++ ) 
g.timePlanarityTest( root, out ); 

} 

} 

public static void speedTestSimilarWheelGraphsWithlncreasingSizes ( final 
PrintStream out , final int from , final int to , final int increment , final int 
repetitions , final int numerator, final int denominator ) { 
for ( int i = from ; i <= to ; i += increment ) { 

final Graph g = new mgtaylor . graph . graphTypes . PlanarMultiWheelGraph ( i , 

3 , true ) ; 

out.println( g.toStringQ ); 

final ArrayList <Vertex> vertices = g . get Vert i ces () ; 
final Vertex root = vertices. get ( get Root Index ( vertices. sizeQ, 
numerator , denominator ) ) ; 
for ( int r = 0; r < repetitions; r++ ) 
g.timePlanarityTest( root, out ); 

} 

} 

public static void speedTestSimilarOrderedGraphsWithlncreasingSizes ( final 
PrintStream out , final int from , final int to , final int increment , final int 
repetitions , final int numerator, final int denominator ) { 
for ( int i = from ; i <= to ; i += increment ) { 
final Graph g = new 

mgtaylor . graph . graphTypes . OrderedFaceTrisectionGraph ( i ); 
out.println( g.toStringQ ); 

final ArrayList <Vertex> vertices = g . get Vert i ces () ; 
final Vertex root = vertices . get ( getRootlndex ( vertices . size () , 
numerator , denominator ) ) ; 
for ( int r = 0; r < repetitions; r++ ) 
g.timePlanarityTest( root, out ); 

} 

} 

public static void speedTestSimilarRandomGraphsWithlncreasingSizes ( 
final PrintStream out , 

final mgtaylor . graph . graphTypes . RandomMaximalPlanarGraphGenerator gg , 

final int from , 

final int to , 

final int increment , 
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105 final int repetitions , 

106 final int numerator , 

107 final int denominator 

108 ) { 

109 for ( int i = from ; i <= to ; i 4= increment ) { 
no final Graph g = gg . generateGraph ( i ); 

out.println( g.toStringQ ); 

112 final ArrayList <Vertex> vertices = g . get Vert ices () ; 

113 final Vertex root = v e r t i c e s . get ( getRootlndex ( ve r t i c e s . s i z e ( ) 
numerator , denominator ) ) ; 

114 for ( int r = 0; r < repetitions; r++ ) 

115 g.timePlanarityTest( root, out ); 

116 } 



117 



1 10 



} 



119 public static void speedTestGraphWithReducingEdges ( 

120 final PrintStream out , 

121 final mgtaylor . graph . graphTypes . ReduceableBiconnectedGraphGenerator 

122 final int increment , 

123 final int repetitions 
) { 

125 performCodeWarmup ( gg . generateGraph ( gg . numberOfRemovableEdges ( ) ) , 
CODE_WARMUP_REPETITIONS ) ; 

126 for ( int i = gg . numberOfRemovableEdges ( ) ; i >= 0; i — = increment ) { 

127 final Graph g = gg . generateGraph ( i ); 

128 out.println( g.toStringQ ); 

129 for ( int r = 0; r < repetitions; r++ ) 

130 g . timePlanarityTest ( null, out ); 

131 } 



} 



134 public static void performCodeWarmup ( final Graph g, final int repetitions ) { 

135 final Array List <Vertex> vertices = g . get Vertices () ; 

136 final Random random = new Random () ; 

137 for ( int r = 0; r < repetitions ; r^+ ) 

138 g . s i le n t P lanar it y Tes t ( ve r t i c e s . get ( random . nextlnt ( ve r t i c e s . s i z e ( ) ) 

) ); 

139 System . gc ( ) ; 



} 



142 private static final int CODE_WARMUP_REPETTTIONS = 50000; 

143 private static final int REPETITIONS = 1000; 

144 private static final int REPETITIONS_LARGE = 100; 

145 private static final int REPETITIONS ROOTS = 3000; 

147 private static final int DIFFERENT_ROOTS = 0; 

148 private static final int DIFEERENT_ROOT3_NUMBER_OF_TE3T3 = 10; 

149 private static final int DIFFERENT_SIZES = DIFFERENT_ROOTS + 4 * 
DrFFERENT_ROOTS_NUMBER_OF_TESTS ; 

150 private static final int DIFFERENT_SIZES_NUMBER_OF_TESTS = 5; 

151 private static final int LARGE_SIZES = DIFFERENT_SIZES + 4 * 
DIFFERENT_SIZES_NUMBER_OF_TESTS ; 

152 private static final int LARGE_SIZES_NUMBER_OF_TESTS = 5; 

153 private static final int EDGE_SIZES = LARGE_SIZES + 4 * 
LARGE_SIZES_NUMBER_OF_TESTS ; 

private static final int EDGE_SIZES_NUMBER_OF_TESTS = 5; 
public static void performTestCase ( final int testCase ) { 

158 /** 

159 * Test Case Graph Tested 

160 * —1 Reduceable Random Maximal Planar Graph (2500 vertices , 2500 — 
4750 edges in 50 edge increments) — 1st Vertex As Root 

* - 9 Planar Wheel Graph (250-2500 Vertices in 250 increments) - All 
Roots 
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165 
166 
167 
168 
169 
170 



185 
ISO 
187 



* 10 - 19 Triangular Prism Graph (250-2500 Vertices in 250 
increments) — All Roots 

* 20 - 29 Ordered Maximal Planar Graph (250-2500 Vertices in 250 
increments) — All Roots 

* 30 - 39 Random Maximal Planar Graph (250-2500 Vertices in 250 
increments) — All Roots 



* 40 

* 41 

* 42 

* 43 

* 44 

* 45 
Root 

* 46 
Root 

* 47 
Root 

* 48 
Root 

* 49 
Root 

* 50 
as Root 

* 51 
as Root 

* 52 

Vertex as Root 

* 53 
Vertex as Root 



Planar Wheel Graph (40:3:4498 Vertices) - 1st Vertex as Root 
Planar Wheel Graph (40:3:4498 Vertices) - Nth Vertex as Root 
Planar Wheel Graph (40:12:4498 Vertices) - l/4Nth Vertex as Root 
Planar Wheel Graph (40:6:4498 Vertices) - i/2Nth Vertex as Root 
Planar Wheel Graph (40:12:4498 Vertices) - 3/ 4 Nth Vertex as Root 
Triangular Prism Graph (40:3:4498 Vertices) — 1st Vertex as 

Triangular Prism Graph (40:3:4498 Vertices) — Nth Vertex as 

Triangular Prism Graph (40:12:4498 Vertices) - i/4Nth Vertex as 

Triangular Prism Graph (40:6:4498 Vertices) — !/2Nth Vertex as 

Triangular Prism Graph (40:12:4498 Vertices) - 3/ 4 Nth Vertex as 



Ordered Maximal Planar Graph (40:3:4498 Vertices) 

Ordered Maximal Planar Graph (40:3:4498 Vertices) 

Ordered Maximal Planar Graph (40:12:4498 Vertices) 
■loot 

Ordered Maximal Planar Graph (40:6:4498 Vertices) 



* 54 Ordered Maximal Planar Graph (40:12:4498 Vertices) 
Vertex as Root 

* 55 Random Maximal Planar Graph (40:3:4498 Vertices) - 
as Root 

* 56 
as Root 

* 57 



Random Maximal Planar Graph (40:3:4498 Vertices) 



Random Maximal Planar Graph (40:12:4498 Vertices) 
Vertex as Root 

* 58 Random Maximal Planar Graph (40:6:4498 Vertices) - 
Vertex as Root 

* 59 Random Maximal Planar Graph (40:12:4498 Vertices) 
Vertex as Root 



- 1st Vertex 

- Nth Vertex 

- i/4Nth 

- i/2Nth 

- 3/ 4 Nth 
1st Vertex 
Nth Vertex 

- i/4Nth 
i/2Nth 

- 3/ 4 Nth 



* 60 

* 61 

* 62 
Root 

* 63 
Root 

* 64 
Root 

* 65 
Root 

* 66 
Root 

* 67 
as Root 

* 68 
as Root 

* 69 
as Root 

* 70 

Vertex t 

* 71 

Vertex i 

* 72 
Vertex as Root 



Planar Wheel Graph (502:30:15000 Vertices) - 1st Vertex as Root 

Planar Wheel Graph (502:30:15000 Vertices) - Nth Vertex as Root 

Planar Wheel Graph (502:60:15000 Vertices) - l/4Nth Vertex as 

Planar Wheel Graph (502:30:15000 Vertices) - l/ 2Nth Vertex as 

Planar Wheel Graph (502:60:15000 Vertices) - 3/ 4 Nth Vertex as 



Triangular 


Prism 


Graph 


(501:30:14999 


Vertices) — 1st Vertex as 


Triangular 


Prism 


Graph 


(501:30:14999 


Vertices) — Nth Vertex as 


Triangular 


Prism 


Graph 


(501:60:14999 


Vertices) - i/4Nth 


Vertex 


Triangular 


Prism 


Graph 


(501:30:14999 


Vertices) - 1/aNth 


Vertex 


Triangular 


Prism 


Graph 


(501:60:14999 


Vertices) - 3/ 4 Nth 


Vertex 


Ordered Maximal 


Planar 


Graph (501:30 


14999 Vertices) - 


1st 


Root 












Ordered Maximal 


Planar 


Graph (501:30 


14999 Vertices) - 


Nth 


Root 












Ordered Maximal 


Planar 


Graph (501:60 


14999 Vertices) - 


lANth 
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198 


* 73 




Ordered 


Maximal 


Planar Graph 


(501:30:14999 Vertices) - 


1/2 Nth 




Vertex 


as 


Root 










199 


* 74 




Ordered 


Maximal 


Planar Graph 


(501:60:14999 Vertices) - 


3/ 4 Nth 




Vertex 


as 


Root 










200 


* 75 




Random 


Maximal 


Planar Graph 


(501:30:14999 Vertices) - 


1 st 




Vertex 


as 


Root 










201 


* 76 




Random 


Maximal 


Planar Graph 


(501:30:14999 Vertices) - 


Nth 




Vertex 


as 


Root 










202 


* 77 




Random 


Maximal 


Planar Graph 


(501:60:14999 Vertices) - 


i/4Nth 




Vertex 


as 


Root 










203 


* 78 




Random 


Maximal 


Planar Graph 


(501:30:14999 Vertices) - 


i/2Nth 




Vertex 


as 


Root 










204 


* 79 




Random 


Maximal 


Planar Graph 


(501:60:14999 Vertices) - 


3/4Nth 




Vertex 


as 


Root 










205 


* 80 




Planar 


Wheel Graph (15000 Vertices , Reducing Edges) — 


1st 




Vertex 


as 


Root 










206 


* 81 




Planar 


Wheel Graph (15000 Vertices , Reducing Edges) — 


Nth 




Vertex 


as 


Root 










207 


* 82 




Planar 


Wheel Graph (15000 Vertices , Reducing Edges) — 


i/4Nth 




Vertex 


as 


Root 










208 


* 83 




Planar 


Wheel Graph (15000 Vertices , Reducing Edges) — 


i/2Nth 




Vertex 


as 


Root 










209 


* 84 




Planar 


Wheel Graph (15000 Vertices , Reducing Edges) — 


3/ 4 Nth 




Vertex 


as 


Root 










210 


* 85 




Triangular Prism Graph (14999 Vertices , Reducing Edges 


) - 1st 




Vertex 


as 


Root 










211 


* 86 




Triangular Prism Graph (14999 Vertices , Reducing Edges 


) - Nth 




Vertex 


as 


Root 










212 


* 87 




Triangular Prism Graph (14999 Vertices , Reducing Edges 


) - V* 




Nth Vertex 


as Root 










213 


* 88 




Triangular Prism Graph (14999 Vertices , Reducing Edges 


) - V* 




Nth Vertex 


as Root 










214 


* 89 




Triangular Prism Graph (14999 Vertices , Reducing Edges 


) ~ 3 /4 




Nth Vertex 


as Root 










215 


* 90 




Ordered 


Maximal 


Planar Graph 


(14999 Vertices , Reducing 


Edges ) 




— 1st Vertex as Root 








216 


* 91 




Ordered 


Maximal 


Planar Graph 


(14999 Vertices , Reducing 


Edges ) 




— Nth Vertex as Root 








217 


* 92 




Ordered 


Maximal 


Planar Graph 


(14999 Vertices , Reducing 


Edges ) 




- i/4Nth 


Vertex as 


Root 








218 


* 93 




Ordered 


Maximal 


Planar Graph 


(14999 Vertices , Reducing 


Edges ) 




- V 2Nth 


Vertex as 


Root 








219 


* 94 




Ordered 


Maximal 


Planar Graph 


(14999 Vertices , Reducing 


Edges ) 




- 3/ 4 Nth 


Vertex as 


Root 








220 


* 95 




Random 


Maximal 


Planar Graph 


(14999 Vertices , Reducing 


Edges) — 




1st Vertex 


as Root 










221 


* 96 




Random 


Maximal 


Planar Graph 


(14999 Vertices , Reducing 


Edges) — 




Nth Vertex 


as Root 










222 


* 97 




Random 


Maximal 


Planar Graph 


(14999 Vertices , Reducing 


Edges) — 




i/4Nth Vertex as Root 








223 


* 98 




Random 


Maximal 


Planar Graph 


(14999 Vertices , Reducing 


Edges) — 




l/2Nth Vertex as Root 








224 


* 99 




Random 


Maximal 


Planar Graph 


(14999 Vertices , Reducing 


Edges) — 




3/4Nth Vertex as Root 








225 


*/ 














226 


if ( testCase < ) 


{ 








227 


final 


Graph g; 










228 


final 


int size = 


100; 








229 


switch ( 


testCase ) { 








230 


case 


-2 












231 


g = new mgtaylor . graph . graphTypes . 


TriangularPrismMaximalPlanar Graph ( 


232 


break ; 










233 


case 


-3: 












234 


g 


= new mgtaylor . graph . graphTypes . 


OrderedFaceTrisectionGraph ( size ); 
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235 
236 
237 
238 



239 
240 
241 
242 
243 

244 
245 
246 



247 
248 
249 
250 

251 
252 
253 

255 
256 
257 
258 
259 
260 

261 
262 
263 
264 
265 
266 
267 
268 
269 
270 
271 
272 
273 

274 
275 

276 
277 
278 
279 
280 
281 
282 



283 
284 
285 
286 
287 



break ; 
case —4: 

final mgtaylor . graph . graphTypes . RandomMaximalPlanarGraphGenerator gg 
= new 

mgtaylor . graph . graphTypes . RandomMaximalPlanarGraphGenerator ( size 

); 

g = gg . generateGraph ( size ); 

break ; 
case — 1: 
default : 

g = new mgtaylor . graph . graphTypes . PlanarMultiWheelGraph ( size , 3, 
true ) ; 
break ; 

} 

final mgtaylor . graph . graphTypes . ReduceableGraphGenerator rgg = new 
mgtaylor . graph . graphTypes . ReduceableGraphGenerator ( g , 
g . get Vertices () . get ( ) ); 

performCodeWarmup ( g , CDDE_WAPJvlTJP_REPETlTIONS ) ; 

final int steps = 100; 

for ( int e = 0; e <= steps ; e++ ) { 

final Graph graph = rgg . generateGraph ( 

e*rgg . numberOfRemovableEdges () / steps ) 

System . out . println ( graph . to St ring ( ) ) 

for (int i = 0; i < . 5 * REPETITIONS ; i++ ) 
graph . timePlanarityTest () ; 

} 

} else if ( DIFFERENT_ROOTS <= testCase && testCase < DIFFERENT_SIZES ) { 
final Graph g; 
f i nal int size; 

final double r e pe t i t io n f ac t or ; 

switch ( (testCase — DIFFERENT_ROOTS) % DlFFERENT_ROOTS_NUMBER_OF_TE3TS 
) { 



case 
case 
case 
case 



default 

} 

switch ( (testCase - DIFFERENT_ROOTS) / DlFFERENT_ROOTS_NUMBER_OF_TESTS 
) { 

case 1 : 

g = new mgtaylor . graph . graphTypes . TriangularPrismMaximalPlanarGraph ( 
size ) ; 
break ; 
case 2: 

g = new mgtaylor . graph . graphTypes . OrderedFaceTrisectionGraph ( size ); 
break ; 
case 3: 

final mgtaylor . graph . graphTypes . RandomMaximalPlanarGraphGenerator gg 
= new 

mgtaylor . graph . graphTypes . RandomMaximalPlanarGraphGenerator ( size 






s 


ze 


= 250; 


repetition 


factor = 


L ; 


break ; 


1 


s 


ze 


= 500; 


repetition 


factor = 


I ; 


break ; 


2 


s 


z e 


= 750; 


repetition 


factor = 


L; 


break ; 


3 


s 


z e 


= 1000 


repetition 


factor = 


1 


break ; 


4 


s 


ze 


= 1250 


repetition 


factor = 


1 


break ; 


5 


s 


ze 


= 1500 


repetition 


factor = 


1 


break ; 


6 


s 


ze 


= 1750 


repetition 


factor = 





75; break; 


7 


s 


z e 


= 2000 


repetition 


factor = 





5 ; break ; 


8 


s 


z e 


= 2250 


repetition 


factor = 





4 ; break ; 


9 


size 


= 2500 


repetition 


factor = 





3 ; break ; 



size = 1000; r ep et it i o n _ f ac t or = 1; break; 



) 



. generateGraph ( size ); 



g = gg 
break ; 
case 0: 
default : 

g = new mgtaylor . graph . graphTypes . PlanarMultiWheelGraph ( size , 3. 
true ) ; 
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2SS 
289 
290 
291 

292 
293 
294 
295 

296 
297 
298 
299 
300 
301 
302 
303 

304 
305 

306 
307 

308 
309 
310 
311 
312 

313 
314 
315 
316 



317 
318 
319 

320 
321 
322 
323 

324 
325 

326 
327 
328 
329 
330 
331 



338 
339 
340 



break ; 



} 



numer = 





denom = 


1 


incr = 


3 ; break ; 


numer = 


1 


denom = 


1 


incr = 


3 ; break ; 


numer = 


1 


denom = 


4 


incr = 


12; break; 


numer = 


1 


denom = 


2 


incr = 


6 ; break ; 


numer = 


3 


denom = 


1 


incr = 


12; break; 


numer = ; 


denom = 1 ; 


i ncr = 3 ; 


break ; 



performCodeWarmup ( g , CODE_WARMUP_REPETnTIONS ) ; 
speedTestGraphWithDifferentRoot ( System . out , g, (int) 
(REPETITIONS_ROOTS * repetition_factor ) ); 
} else if ( DIFFERENT _ SIZES <= testCase && testCase < ( LARGE_SIZES ) ) { 
final Graph g; 

final int numer, denom, incr; 

switch ( (testCase - DIFFERENT_ SIZES ) % DIFFERENT_SIZES_NUMBER_OF_TESTS 
) { 

case 0: 
case 1 : 
case 2: 
case 3: 
case 4: 
default 
} 

switch ( (testCase - DIFFERENT_SIZES) / DIFFERENT_SIZES_NUMBER_OF_TESTS 
) { 

case 1 : 

g = new mgtaylor . graph . graphTypes . TriangularPrismMaximalPlanarGraph ( 
1000 ) ; 

performCodeWarmup ( g , CODE_WARMUP_REPETlTIONS ) ; 

speedTestSimilarTriangleGraphsWithlncreasingSizes ( System . out , 42, 
4500, incr, REPETITIONS, numer, denom ); 
break ; 
case 2: 

g = new mgtaylor . graph . graphTypes . OrderedFaceTrisectionGraph ( 1000 ); 
performCodeWarmup ( g , CODE_WARMUP_REPETlTIONS ) ; 

speedTestSimilarOrderedGraphsWithlncreasingSizes ( System . out , 42, 
4500, incr, REPETITIONS, numer, denom ); 
break ; 
case 3: 

final mgtaylor . graph . graphTypes . RandomMaximalPlanarGraphGenerator gg 
= new 

mgtaylor . graph . graphTypes . RandomMaximalPlanarGraphGenerator ( 4500 

); 

g = gg . generateGraph ( 1 000) ; 

performCodeWarmup ( g , CODE_WARMUP_REPETlTIONS ) ; 

speedTestSimilarRandomGraphsWithlncreasingSizes ( System . out , gg , 42, 

4500, incr, REPETITIONS, numer, denom ); 

break ; 
case 0: 
default : 

g = new mgtaylor . graph . graphTypes . PlanarMultiWheelGraph ( 1000, 3, 
true ) ; 

performCodeWarmup ( g , CODE_WARMUP_REPETlTIONS ) ; 

speedTestSimilarWheelGraphsWithlncreasingSizes ( System . out , 40, 
4498, incr, REPETITIONS, numer, denom ); 
break ; 

} 

} else if ( LARGE_SIZES <= testCase &fe testCase < EDGE_SIZES ) { 
final Graph g; 

final int numer, denom, incr; 

switch ( (testCase - LARGE_SIZES ) % LARGE_SIZES_NUMBER_OF_TESTS ) { 



332 


case 


numer = 





denom = 


1 


incr 


= 30 


break 


333 


case 1 


numer = 


1 


denom = 


1 


incr 


= 30 


break 


334 


case 2 


numer = 


1 


denom = 


4 


incr 


= 60 


break 


335 


case 3 


numer = 


1 


denom = 


2 


incr 


= 30 


break 


336 


case 4 


numer = 


3 


denom = 


4 


incr 


= 60 


break 


337 


default: numer = 0; 


denom = 1 ; 


incr = 


30; break; 



switch ( (testCase - LARGE_SIZES ) / LARGE_SIZES_NUMBER_OF_TESTS ) { 
case 1: 
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3-12 
343 

344 
345 
346 
347 
348 

3 19 
350 
351 
352 



353 
354 
355 

356 
357 
358 
359 

360 
361 

362 
363 
364 

365 
366 
367 
368 



375 
376 
377 
378 
379 

380 
381 
382 
383 
384 
385 
386 
387 

388 
389 
390 
391 
392 



g = new mgtaylor . graph . graphTypes . TriangularPrismMaximalPlanarGraph ( 
1000 ) ; 

performCodeWarmup ( g , CODE_WARMUP_REPETTTIONS ) ; 

speedTestSimilarTriangleGraphsWithlncreasingSizes ( System . out , 501, 
14999, incr, REPETITIONS_LARGE , numer , denom ); 
break ; 
case 2: 

g = new mgtaylor . graph . graphTypes . OrderedFaceTrisectionGraph ( 1000 ) 
performCodeWarmup ( g , CODE_WARMUP_PJTETTTIONS ) ; 

speedTestSimilarOrderedGraphsWithlncreasingSizes ( System . out , 501, 

14999, incr, REPETITIONS_LARGE , numer, denom ); 
break ; 

case 3: 

final mgtaylor . graph . graphTypes . RandomMaximalPlanarGraphGenerator gg 
= new 

mgtaylor . graph . graphTypes . RandomMaximalPlanarGraphGenerator ( 
15000 ) ; 
g = gg . generateGraph ( 1 000) ; 

performCodeWarmup ( g , CODE_WARMUP_REPETlTIONS ) ; 

speedTestSimilarRandomGraphsWithlncreasingSizes ( System . out , gg , 
502, 15000, incr, REPETITIONS_LARGE, numer, denom ); 
break ; 

case 0: 

default : 

g = new mgtaylor . graph . graphTypes . PlanarMultiWheelGraph ( 1000, 3, 
true ) ; 

performCodeWarmup ( g , CODE_WARMUP_REPETlTIONS ) ; 

speedTestSimilarWheelGraphsWithlncreasingSizes ( System . out , 502 , 

15000, incr, REPETITIONS_LARGE , numer, denom ); 
break ; 

} 

} else if ( EDGE_SIZES <= testCase && testCase < (EDGE_SIZES + 4 * 
EDGE_SrZES_NUMBER_OF_TESTS) ) { 

final mgtaylor . graph . graphTypes . ReduceableBiconnectedGraphGenerator gg ; 

final Graph g; 

final int size , numer, denom, incr; 

switch ( (testCase - EDGE_SIZES) % EDGE_SrZES_NUMBER_OF_TESTS ) { 



369 


case 


numer = 





denom = 


1 


incr 


= 30 


break 


370 


case 1 


numer = 


1 


denom = 


1 


incr 


= 30 


break 


371 


case 2 


numer = 


1 


denom = 


4 


incr 


= 60 


break 


372 


case 3 


numer = 


1 


denom = 


2 


incr 


= 30 


break 


373 


case 4 


numer = 


3 


denom = 


4 


incr 


= 60 


break 


374 


default: numer = 0; 


denom = 1 ; 


incr = 


30; break; 



} 

switch ( (testCase - EDGE_SIZES) / EDGE_SrZES_NUMBER_OF_TESTS ) { 
case 1 : 

size = 14999; 

g = new mgtaylor . graph . graphTypes . TriangularPrismMaximalPlanarGraph ( 
size ) ; 
break ; 
case 2: 

size = 14999; 

g = new mgtaylor . graph . graphTypes . OrderedFaceTrisectionGraph ( size ) 
break ; 
case 3: 

size = 14999; 

g = new mgtaylor . graph . graphTypes . RandomMaximalPlanarGraphGenerator ( 

size ). generateGraph ( size ) ; 

break ; 
case 0: 
default : 

size = 15000; 

g = new mgtaylor . graph . graphTypes . PlanarMultiWheelGraph ( size , 3, 
true ) ; 
break ; 



APPENDIX D. JAVA SOURCE CODE 352 



394 
395 



397 
398 

400 
401 
402 
403 
404 
405 
406 
407 

408 
409 
410 
111 
412 

413 
414 
415 
116 
417 
418 
419 

121 
422 
423 



} 



gg = new mgtaylor . graph . graphTypes . ReduceableBiconnectedGraphGenerator ( 
g, g.getVertices().get( getRootIndex( g.vertexSizeQ, numer , denom ) ) 

); 

speedTestGraphWithReducingEdges ( System . out , gg , incr , 
REPETITIONS_LARGE ) ; 



args ) { 



) ) { 



public static void main( final String 
if ( args . length > ) { 

for ( int i = 0; i < args . length ; i++ ) { 
String testCase = args [ i ] ; 

if ( t est C ase . equalslgnor e C ase ( "--Roots' 
String file = args[++i]; 

int graph = Integer . parselnt ( args[++i] ); 
j a va . u t i 1 . Array List <St ring > graphs = 
GraphExtractorLogParser . parseLogFile ( file ); 
final Graph g = new Graph ( graphs . get ( graph ) ); 
file = null; 
graphs = null ; 

performCodeWarmup ( g , CODE_WARMUP_REPETlTrONS ) ; 

speedTestGraphWithDifferentRoot ( System . out , g, REPETITIONS_ROOTS 

); 

} else { 

performTestCase ( Integer . parselnt ( testCase ) ); 
System . gc ( ) ; 



} 



} 



} else 

performTestCase ( ) 

System .out. close () ; 



D.4.2 mgtaylor. graph. test. parsers. GraphExtractorLogParser 

package mgtaylor . test . parsers ; 



import java . io . BufferedReader ; 
import java . io . File ; 
import java . io . FileReader ; 

public class GraphExtractorLogParser { 

public static j ava . ut i 1 . ArrayList <String > parseLogFile ( final String filename 
) { 

final java . util . ArrayList <String > graphs = new 
java . util . ArrayList<String >() ; 
final File in = new File ( filename ) ; 
try { 

final BufferedReader br = new BufferedReader ( new FileReader ( 

in ) ); 

String string = br . readLine ( ) ; 
while ( string != null ) { 
17 if ( s t r i n g . start s Wit h ( "nodes { ") ) { 

is final StringBuffer graphString = new StringBuffer ( string ) ; 

while ( ! string . equals ( "}" ) ) { 
string = br . readLine () ; 
graphString . append ( '\n' ); 
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graphString . append ( string ); 

} 

graphs. add ( graphString . toString ( ) ); 

25 } 

26 string = br . readLine ( ) ; 
} 

br . close ( ) ; 

29 } catch ( Exception e ) { 

30 } 

return graphs ; 

} 

/* * 

* @param args 

* / 

37 public static void main( final String]] args) { 

38 // TODO Auto— generated method stub 
for ( String arg : args ) { 

j a va . u t i 1 . Array List <St ring > graphs = parseLogFile ( arg ) 
for ( String graph : graphs ) { 
System . out . println ( graph ); 
System .out.printlnQ; 

} 

45 } 

46 } 



D.4.3 mgtaylor. graph. test. parsers. GraphStatsLogParser 



package mgtaylor . test . parsers 



mport 
mport 
mport 
mport 
mport 

import java . io 
import mgtaylor . graph . Graph 



ava . io 
ava . io 
ava . io 
ava . io 
ava . io 



BufferedReader : 
BufferedWriter : 
File ; 

FileReader ; 
FileWriter ; 
PrintWriter ; 



public class GraphStatsLogParser { 

// "[GC [DefNew: 101476K->4947K( 108864K) , 0.0323195 sees] 
272464K->175936K(1560768K) , 0.0323640 sees] [Times: user=0.03 sys=0.00, 
real=0.03 sees] " 

public static final boolean DISPLAY_NUMBER_OF_VERTICES = false; 
public static final boolean DBPLAY_NUMBER_OF_EDGES = false; 

public static final boolean DBPI^Y_NUMBER_OF_SEGMENTS = true ; 

public static String extendFilename ( final String filename , final String 
extension , final String appendString ) { 

return filename . replace All ( extension + "$", appendString + extension ); 

} 

public static void parseLogFile ( final String filename ) { 
File in = new File( filename ); 

File out = new File( extendFilename ( filename, ".log", "_Depths" ) ): 

if ( ! in . exists () || out.existsQ ) { 

System . err . pr i nt 1 n ( "Check whether input file exists or output files do 
not exist . " ) ; 
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return ; 

} 

final PrintWriter writer ; 
try { 

writer = new PrintWriter ( new BufferedWriter ( new FileWriter( out ) ) ) 
} catch ( Exception e ) { 
e. printStackTrace () ; 
return ; 

} 

try { 

final BufferedReader br = new BufferedReader ( new FileReader( 

in ) ); 

Graph g = null ; 

String string = br . readLine ( ) ; 

long vertices = 0; 

long edges = 0; 

int root = -100; 

while ( string != null ) { 

if ( string . startsWith ( "nodes { ") ) { 
String graphString = string ; 
while ( ! string . equals ( "}" ) ) { 
string = br . readLine () ; 

graphString = graphString + "\n" + string; 

} 

g = new Graph ( graphString ) ; 
vertices = g . ver t exS ize ( ) ; 
edges = g . edge S ize () ; 
string = br . readLine () ; 

System . out . println ( vertices + "\t" + edges ); 
root = —1; 
continue ; 

} else if ( string . startsWith ( "Root: " ) ) { 
String s = string . substring (6) ; 
int 1 = s . indexOf ( ' [ ' ) ; 
if ( 1 > ) { 

s = s.substring( 0, 1 ); 

System . out . println ( s + " : " + string ); 

} 

int r = Integer . parselnt ( s ) ; 
if ( r != root && g != null ) { 

root = r ; 

g.DFS( g. getVertices () . get ( r - 1 ) ); 

g.generateSegmentsQ ; 

if ( DISPLAY_NUMBER_OF_VERTICES ) 

writer, print ( g.vertexSizeQ + "\t" ); 
if ( DBPIAY_IWMBm_OF_EBGES ) 

writer, print ( g.edgeSizeQ + "\t" ); 
writer . print ( r + "\t" + g . calculateAverageSegmentDepth ( ) ); 
if ( DBPIAY_NUMBFJl_OF_SFi3MENTS ) 

writer . print ( "\t" + g . getNumberOfSegments ( ) ); 
writer . println () ; 

} 

} 

string = br . readLine () ; 

} 

br . close ( ) ; 
writer . close () ; 
} catch ( Exception e ) { 
try { 

writer . close ( ) ; 
} catch ( Exception ex ) {} 
e. printStackTrace () ; 
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} 



public static final void main( String 
for ( final String filename : args 
parseLogFile ( filename ); 

} 



args ) { 



D.4.4 mgtaylor. graph. test. parsers. NewGCLogParser 



i package mgtaylor . test . parsers 



mport j ava . 
mport java . 
mport java . 
mport j ava . 
mport j ava . 
mport java . 



io . BufferedReader : 
io . BufferedWriter : 
io . File ; 
io . FileReader ; 
io . FileWriter ; 
io . PrintWriter ; 



mport java . util . regex . Matcher ; 
import java . util . regex . Pattern ; 

import mgtaylor . graph . Graph ; 

public class NewGCLogParser { 

private static final String GC STRING 
"\\[.*(\\d+\\.\\d+)\\s+secs\\]\\s+\\ [Times 
Pattern GC PATTERN 



public static final 

GC_STRING + " $ " ) ; 
public static final 
Graph. ROOT_STRING + 
public static final 
Graph . START_STRJNG 
public static final 
Graph. DFS_STRING + 
public static final 
Graph. GENERATION_STRTNG + " 
public static final Pattern 
Graph. EMBEDDrNG_STRING + ": 
public static final Pattern 
Graph. EDGE_SIDES_STRING + " 



.+\\]\\s*" ; 

= Pattern . compile ( 



Pattern ROOT_PATTERN = Pattern . compile ( "~' 

": ( [~\\ □ *?)(" + GC_STRING + ")?$" ); 
Pattern START_PATTERN = Pattern . compile ( 
" . * $ " ) ; 

Pattern DFS_PATTERN = Pattern . compile ( 

: (\\d + ).*$" , Pattern . CASE_INSENSITIVE ); 



Pattern 



GENERATION_PATTERN 
(\\d+) .*$" ) ; 

EMBEDD1NG_PATTERN 

(\\d+) .*$» ) ; 

EDGE_SIDES_PATTERN 
(\\d+) .*$" ) ; 



= Pattern . compile ( 
= Pattern . compile ( 
= Pattern . compile ( 



private static final 

private static final 

private static final 

private static final 

private static final 

private static final 

private static final 



boolean OUTPUT TOTAL = true; 

boolean OUTPUT DFS = false 

boolean OUTPUT_GENERATION = false 

boolean OUTPTJT_EMBEDDlNG = false 
boolean OTJTPUT_NON_EMBEDDING = false 

boolean OUTPUT EDGES = true; 

boolean OUTPUT DEPTHS = true ; 



private static final boolean DEPTHS_DISPLAY_NUMBER_OF_VERTICES 
private static final boolean DEPTHS_DISPIAY_NUMBER_OF_EDGES 
private static final boolean DFPTHS_DISPIAY_NUMBFJl_OF_SF£!MENTS 



false 
false 
true ; 



public static String extendFilename ( final String filename , final String 
extension , final String appendString ) { 

return filename . replace All ( extension + "$", appendString + extension 

} 

©Suppress Warnings ( " unused " ) 

public static void parseLogFile ( final String filename ) { 
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final File in = new File( filename ); 

final File out = new File ( extendFilename ( filename, ".log", 

" .Total " ) ) ; 

final File out_DFS = new File( extendFilename ( filename, ".log", 

"_DFS" ) ); 

final File out _ Generation = new File( extendFilename ( filename, ".log", 
".Generation" ) ); 

final File out_Embedding = new File( extendFilename ( filename, ".log", 
" .Embedding " ) ) ; 

final File out_NonEmbedding = new File ( extendFilename ( filename , 
".log", VNonEmbedding" ) ); 

final File out_Edges = new File( extendFilename ( filename, ".log", 
" _EdgeSides " ) ) ; 

final File out_Depths = new File( extendFilename ( filename, ".log", 

" .Depths " ) ) ; 

if ( in. exists () &fe 

(! OUTPUT JTOTAL || ! out . exists ()) &fe 

(!OUTPUT_DFS || ! out_DFS . exist s ()) && 

(!OUTPUT_GENERATION || ! out Generation . exists ()) &fe 

(!OUTPUT_EMBEDDING || ! out^Embedding . exi s t s ( ) ) && 

( ! OUTPUT_NON_EMBEDDTNG | | ! out _ NonEmbedding . e x i s t s ( ) ) && 
(!OUTPUT_EDGES || ! out_Edges . exists ()) && 

(! OUTPUT JDEPTHS || ! out Depths . exists () ) 

) { 
} else { 

System . err . pr i nt 1 n ( "Check whether input file exists or output files do 
not exist . " ) ; 
return ; 

} 

final PrintWriter writer ; 

final PrintWriter writer_DFS ; 

final PrintWriter writ er _ Generation ; 

final PrintWriter writer_Embedding ; 

final PrintWriter writer_NonEmbedding ; 

final PrintWriter writer_Edges ; 

final PrintWriter writer_Depths ; 

try { 

if ( OUTPUT_TOTAL ) writer = new PrintWriter ( new 

BufferedWriter ( new FileWriter( out ) ) ); 
else writer = null ; 

if ( OUTPUT_DFS ) writer_DFS = new PrintWriter ( new 

BufferedWriter ( new FileWriter( out^DFS ) ) ); 
else writer DFS = null ; 

if ( OUTPUT_GENERATION ) writer_Generation = new PrintWriter ( new 
BufferedWriter ( new FileWriter( out_Generation ) ) ); 
else writ er _ Generation = null; 

if ( OUTPUT_EMBEDDING ) writer_Embedding = new PrintWriter ( new 

BufferedWriter ( new FileWriter( out_Embedding ) ) ) ; 
else writer_Embedding = null ; 

if ( OUTPUT_NON_EMBEDDING ) writer^NonEmbedding = new PrintWriter ( 
new BufferedWriter ( new FileWriter( out_NonEmbedding ) ) ); 
else writer_NonEmbedding = null ; 

if ( OUTPUT_EBGES ) writer_Edges = new PrintWriter ( new 

BufferedWriter ( new FileWriter( out_Edges ) ) ); 
else writer_Edges = null ; 

if ( OUTPUT_DEPTHS ) writer_Depths = new PrintWriter ( new 

BufferedWriter ( new FileWriter( out_Depths ) ) ); 
else writer_Depths = null; 

} catch ( Exception e ) { 
e. printStackTrace () ; 
return ; 

} 
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93 try { 

94 final BufferedReader br = new BufferedReader ( new FileReader( 
in ) ); 

96 String string = br . readLine ( ) ; 

97 long vertices = 0; 

98 long edges = 0; 

99 Graph g = null ; 

100 int r = — 1; 

101 while ( string != null ) { 

102 if ( s t r i n g . st art s Wit h ( "nodes { ") ) { 

103 String graphString = string ; 

104 while ( ! string . equals ( "}" ) ) { 

105 string = br . readLine () ; 

106 graphString = graphString + "\n" + string; 

107 } 

108 g = new Graph ( graphString ) ; 

109 vertices = g . vertexSize ( ) ; 
no edges = g . edge S ize ( ) ; 

in r = -2; 

112 string = br . readLine () ; 

113 System . out . println ( vertices + "\t" + edges ); 

114 continue ; 

115 } 

116 Matcher m_root = ROOT_PATTERN. matcher ( string ); 

117 if ( m_root . matches ( ) ) { 

us String root = m root . group ( 1 ). replaceFirst ( "~\\D+", "" ); 

119 if ( OUTPUT_DFPTHS && ( r = -2 | | r != Integer . parselnt ( root ) 
) ) { 

120 r = Integer . parselnt ( root ); 

121 g.DFS( g . get Vertices (). get ( r — 1 ) ); 

122 g . generateSegments ( ) ; 

123 if ( DEPTHS_DISPLAY_NUMBER_OF_VERTICES ) 

124 writer_Depths . print ( g . vertexSize ( ) + "\t" ); 

125 if ( DFPTHS_DISPLAY_NUMBER_OF_EDGES ) 

126 writer_Depths . print ( g.edgeSizeQ + "\t" ); 

127 writer_Depths . print ( r + "\t" + 

g. calculateAverageSegmentDepth () ) ; 

128 if ( DFPTrIS_DISPIAY_NUMBm_OF_STCMENTS ) { 

129 writer_Depths . print ( "\t" + g . getNumberOfSegments ( ) ); 

130 g . embedSegments ( ) ; 

131 writer_Depths . print ( "\t" + g . c alcu lat eT o t al C o nf lie t s ( ) ); 

132 writer_Depths . print ( "\t" + g . calculateNumberOfBlocks ( ) ); 

133 writer_Depths . print ( "\t" + g.edgeSizeQ ); 

134 writer_Depths . print ( "\t" + 

g. calculateNumberOfFlippableBlocks () ) ; 

135 writer_Depths . print ( "\t" + g . get Permutations (). s i z e ( ) ); 

136 } 

137 writer_Depths . println () ; 

138 } 

139 int gc_count = 0; 

140 Matcher m_start = START_PATTERN. matcher ( string = br . readLine ( ) ) 

141 while ( ! m start . matches ( ) ) 

142 m start = START_PATTERN. matcher ( string = br . readLine ( ) ); 

143 Matcher m_dfs = DFS_PATTERN. matcher ( string = br . readLine ( ) ); 

144 long gc_time = 0; 

145 int gc_temp_count = 0; 

146 while (! m_dfs . matches ( ) ) { 

147 Matcher gc = GC_PATTERN. matcher ( string ); 

148 if ( gc. matches () ) { 

149 gc_time += Math.round( Double . parseDouble ( gc.group(l) ) * 

1000000000 ) ; 

150 gc_temp_count++; 

151 gc_count++; 

152 } else { 
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153 if ( string . compareTo ( "" ) != ) 

154 System . err . println ( string ); 

155 } 

156 m_dfs = DFS_PATTERN. matcher ( string = br . readLine ( ) ); 

157 } 

158 long dfs_time = Long . parseLong ( m_dfs . group ( 1 ) ) — gc_time ; 

159 if (OUTPUT_DFS) writer_DFS . println ( vertices + "\t" + edges + 
"\t" + root + "\t" + dfs_time + "\t" + gc_temp_count ) ; 

leo Matcher regeneration = GENERATION_PATTERN. matcher ( string = 

br . readLine ( ) ) ; 

161 gc_time = 0; 

162 gc_temp_count = 0; 

163 while (! m_generation . matches ( ) ) { 

164 Matcher gc = GC_PATTERN. matcher ( string ); 

165 if ( gc. matches () ) { 

166 gc_time += Math.round( Double . parseDouble ( gc.group(l) ) * 

1000000000 ) ; 

167 gc_temp_count++; 

168 gc_count++; 

169 } else { 

170 if ( string . compareTo ( "" ) != ) 

171 System . err . println ( string ); 

172 } 

173 m_generation = GENEPATION_PATTERN. matcher ( string = 
br . readLine ( ) ) ; 

174 } 

175 long generation_time = Long . parseLong ( m_generation . group ( 1 ) ) — 
gc_time ; 

176 if (OUTPUT_GENERATION) writer_Generation . println ( vertices + "\t" 
+ edges + "\t" + root + "\t" + generation_time + "\t" + 
gc_temp_count ) ; 

177 Matcher m_embedding = EMBEDDING PATTERN. matcher ( string = 
br . readLine ( ) ) ; 

178 gc_time = 0; 

179 gc_temp_count = 0; 

180 while (! m_embedding . matches ( ) ) { 

181 Matcher gc = GC_PATTERN. matcher ( string ); 

182 if ( gc. matches () ) { 

183 gc_time += Math.round( Double . parseDouble ( gc.group(l) ) * 

1000000000 ) ; 

184 gc_temp_count++; 

185 gc_countH — h; 

186 } else { 

187 if ( string . compareTo ( "" ) != ) 

188 System . err . println ( string ); 

189 } 

190 m_embedding = EMBEDDING_PATTERN. matcher ( string = 
br . readLine ( ) ) ; 

191 } 

192 final int gc_nonembed_count = gc_count — gc_temp_count ; 

193 long embedding_time = Long . parseLong ( m_embedding . group ( 1 ) ) — 
gc_time ; 

194 if (OUTPUT_EMBEDDING) writer_Embedding . println ( vertices + "\t" + 
edges + "\t" + root + "\t" + embedding_time + "\t" + 
gc_temp_count ) ; 

195 Matcher m_edge_sides = EDGE_SIDES_PATTERN. matcher ( string = 
br . readLine ( ) ) ; 

196 gc time = 0; 

197 gc_temp_count = 0; 

198 while (! m_edge_sides . matches ( ) ) { 

199 Matcher gc = GC_PATTERN. matcher ( string ); 

200 if ( gc. matches () ) { 

201 gc_time += Math.round( Double . parseDouble ( gc.group(l) ) * 

1000000000 ) ; 

202 gc_temp_count++; 
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203 gc_count++; 

204 } else { 

205 if ( string . compareTo ( "" ) != ) 

206 System . err . println ( string ); 

207 } 

2os m_edge_sides = EDGE_SIDES_PATTERN . matcher ( string = 
br . readLine ( ) ) ; 

209 } 

210 long edge_sides_time = Long . parseLong ( m_edge_sides . group ( 1 ) ) - 
gc_time ; 

211 if (OUTPUT_EDGES) writer_Edges . println ( vertices + "\t" + edges 
"\t" + root + "\t" + edge_sides_time + "\t" + gc_temp_count ); 

212 long total_time = dfs_time + generation_time + edge_sides_time ; 

213 if (OUTPUT_NON_EMBEDDING) writer_NonEmbedding . println ( vertices 
"\t" + edges + "\t" + root + "\t" + total_time + "\t" + 

( gc_nonembed_count + gc_temp_count ) ); 

214 total time += embedding_time ; 

215 if (OUTPUT_TOTAL) writer . println ( vertices + "\t" + edges + "\f 
+ root + "\t" + total_time + "\t" + gc count ) ; 

216 } 

217 string = br . readLine () ; 

218 } 

219 br . close ( ) ; 

220 if (OTJTPUT_TOTAL) writer . close () ; 

221 if (OUTPUT_DFS) writer_DFS . close () ; 

222 if (OTJTPUT_GENERATION) writer_Generation . close () ; 

223 if (OUTPTJT_EMBEDDlNG) writer Embedding . close () ; 

224 if (OUTPUT_NON_EMBEDDING) writer_NonEmbedding . close () ; 

225 if (Ol/IPUT_EDGES) writer_Edges . close () ; 

226 if (OUTPUT_DEPTHS) writer_Depths . close () ; 

227 } catch ( Exception e ) { 

228 try { 

229 if (OUIPTJT_TOTAL) writer . close () ; 

230 if (OUTPUT_DFS) writer_DFS . close () ; 

231 if (OUTPUT_GENERAHON) writer_ Generation . close () ; 

232 if (OUTPUT_EMBEDDING) writer_Embedding . close () ; 

233 if (OUTPUT_NON_EMBEDDING) writer_NonEmbedding . close () ; 

234 if (OUTPUT_EDGES) writer_Edges . close () ; 

235 if (OUTPUT_DEPTHS) writer_Depths . close () ; 

236 } catch ( Exception ex ) {} 

237 e . print St ackTr ace () ; 

238 } 

239 } 

241 public static final void main( String [] args ) { 

242 for ( final String filename : args ) 

243 parseLogFile ( filename ); 

244 } 

245 } 



D.4.5 mgtaylor. graph. test. utilities. ConcatenateFiles 



package mgtaylor. test . utilities ; 
import java . io . * ; 

public class ConcatenateFiles { 

/* * 

* @param args 

* / 

public static void main ( St ring [ ] args) { 
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if ( args . length < 3 ) { 

System . out . pr i nt 1 n ( "Usage: java ConcatenateFiles filel file2 [... 
fileN] outputFile" ); 

System . exit ( 1 ) ; 



} 



1] ) 



File out = new File( args [ args . length 
try { 

PrintWriter writer = new PrintWriter ( new BufferedWriter ( new 
FileWriter ( out, out . exists () ) ) ); 
for ( int i = 0; i < args . length — 1; i^+ ) { 
File in = new File( args[i] ); 
if ( in . exist s () ) { 

BufferedReader br = new BufferedReader ( new FileReader( in ) ) 
String s = null ; 

while ( (s = br . readLine ( ) ) != null ) 

wr i t er . pr in 1 1 n ( s ); 
br . close ( ) ; 



} 



} 



28 writer, close (); 

29 } catch ( IOException e ) { 
e. printStackTrace () ; 

} 



D.4.6 mgtaylor. graph. test. utilities. SplitLogFiles 



package mgtaylor . test . utilities ; 



io . BufferedReader ; 
io . BufferedWriter ; 
io . File ; 
io . FileReader ; 
io . FileWriter ; 
io . PrintWriter ; 
import mgtaylor . test . PlanaritySpeedTest Viewer ; 



mport java . 
mport j ava . 
mport j ava . 
mport java . 
mport java . 
mport j ava . 



public class SplitLogFile { 

private static enum CompareCol { VERTEX, EDGE, ROOT, DEPTHS }; 
private static enum CompareType { ASC, EQ, DESC }; 



19 

20 



private static CompareCol getColumn( final String arg ) { 

final String [] in = { "vertex" , "edge" , "root" , "depths" }; 

final CompareCol [] out = { CompareCol .VERTEX, CompareCol .EDGE, 
CompareCol. ROOT, CompareCol .DEPTHS }; 
for ( int i = 0; i < in . length ; i++ ) 

if ( in [ i ] . compareToIgnoreCase ( arg ) = ) return out [ i ] ; 



} 



throw new IllegalArgumentException ( "Invalid Column Type' 



private static int getColumnlndex ( final CompareCol col 
if ( col = CompareCol .EDGE ) return 1; 

if ( col = CompareCol. ROOT ) return 2; 

return 0; 

} 



) { 



private static String getColumnPostfix ( final CompareCol col ) { 
if ( col = CompareCol. DEPTHS ) 

return "Depths"; 
return " Total " ; 
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} 

private static CompareType getCompareType ( final String arg ) { 
final String [] in = { "ASC", " EQ. " , "DESC" }; 

final CompareType [ ] out = { CompareType . ASC , CompareType . EQ, 
CompareType. DESC }; 

for ( int i = 0; i < in . length ; i++ ) 

if ( in [ i ] . compareToIgnoreCase ( arg ) = ) return out [ i ] ; 
throw new IllegalArgumentException ( "Invalid Comparison Type" ); 



private static boolean compareAgainstType ( final int prev , final int curr , 
final CompareType type ) { 

if ( prev = —1 ) return true; 

if ( type = CompareType. DESC ) 

return prev >= curr ; 
if ( type = CompareType . ASC ) 

return prev <= curr ; 
return prev = curr ; 



private static int UnknownOutputlndex = 1; 



private static String getOutputName ( String [] cols , CompareCol col , 
CompareType comp ) { 

if ( comp = CompareType .EQ ) 

return cols [ getColumnlndex ( col ) ]; 

final int root = Integer . parselnt ( cols [ getColumnlndex ( CompareCol .ROOT ) 

] ); 

final int vert = Integer . parselnt ( cols [ getColumnlndex ( CompareCol .VERTEX 

) ] ); 



if ( root = 


PlanaritySpeedTest Viewer . 


getRootlndex 


( 


vert , 


0, 


1 


) 


return "0" ; 
















if ( root = 


PlanaritySpeedTest Viewer . 


getRootlndex 


( 


vert , 


1 , 


1 


) 


return "N" ; 
















if ( root = 


PlanaritySpeedTest Viewer . 


getRootlndex 


( 


vert , 


1 , 


•1 


) 


return " N4 " ; 
















if ( root = 


PlanaritySpeedTest Viewer . 


getRootlndex 


( 


vert , 


1 , 


2 


) 


return "N2"; 
















if ( root = 


PlanaritySpeedTest Viewer . 


getRootlndex 


( 


vert , 


3 , 


4 


) 


return "3N4" 
















return "U" + 


( UnknownOutputIndex++) ; 















} 



private static final String USAGE = 
"Usage : \n" + 

SplitLogFile <FILENAME > <SPLITC0LUMN > <SPLITC0MPARISQN > 
<0UTPUT_PREFIX >\n" + 
"\n" + 



FILENAME 
SPLITC0LUMN 
SPLITC0MPARIS0N 
0UTPUTPREFIX 



The path of the input file.\n" + 
= [ VERTEX I EDGE I ROOT I DEPTHS ]\n" 
= [ ASC I EQ I DESC ]\n" + 

The prefix for the output files. \n" ; 



public static void main(final String 
if ( args . length != 4 ) { 

System . out . println ( USAGE ); 
return ; 

} 



args) { 



final String filename 

final CompareCol col ; 

final int column; 

final String postfix ; 

final CompareType compare; 



= args [0] : 
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87 final String outputname = args[3]; 

89 try { 

90 col = getColumn( args [1] ) ; 

91 column = getColumnlndex ( col ) ; 

92 postfix = getColumnPostfix ( col ); 

93 compare = getCompareType ( args [2] ) ; 

94 } catch ( IllegalArgumentException e) { 

95 System . out . println ( USAGE ); 

96 return ; 

97 } 

99 File in = new File( filename ); 

100 if ( ! in . exists () ) { 

101 System . err . println ( "Check whether input file exists." ); 

102 return ; 

103 } 

105 PrintWriter writer = null ; 

loe try { 

107 final BufferedReader br = new BufferedReader ( new FileReader( in ) ) ; 

109 int curr = — 1; 

no String string = br . readLine ( ) ; 

in File out ; 

113 while (string != null) { 

114 String [] cols = string . split ( "\t" ) ; 

115 final int prev = curr ; 

116 curr = Integer . parselnt ( cols [column] ); 

117 if ( compareAgainstType ( prev, curr , compare ) ) { 

118 out = new File ( outputname + "-" + getOutputName ( cols , col , 
compare ) + "_" + postfix + ".log" ); 

no try { 

120 if ( writer != null ) 

121 writer . close () ; 

122 writer = new PrintWriter ( new BufferedWriter ( new FileWriter( 
out ) ) ) ; 

123 } catch ( Exception e ) { 

124 e . printStackTrace () ; 

125 br . close () ; 

126 if ( writer != null ) 

127 writer . close () ; 

128 return ; 

129 } 

130 } 

131 writer . print In ( string ); 

132 string = br . readLine () ; 

133 } 

134 br . close ( ) ; 

135 if ( writer != null ) 

136 writer . close ( ) ; 

137 } catch ( Exception e ) { 

138 try { 

139 writer . close ( ) ; 

140 } catch ( Exception ex ) {} 

141 e . print St ackTr ace () ; 

142 } 

144 } 

145 } 
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D.5 GUI Files 



D.5.1 mgtaylor. display. AngleHighlight View 

< 

package mgtaylor . display ; 

import java . awt . * ; 
import java. awt . geom . * ; 
import java. util .*; 

import mgtaylor . layout . * ; 
import mgtaylor . layout . event . * ; 
import mgtaylor . planarity . event . * ; 

import mgtaylor . graph . * ; 

public class AngleHighlight View extends Draggable View implements 
PlanarOrderListener { 

/* * */ 

private static final long serialVersionUID = -1624845479870365270L ; 

private static final int ORDERED_INCORRECILY = 0; 
private static final int ORDERED_CLOCKWlSE = 1; 

private static final int ORDERED_ANTICLCCKWISE = 2; 

private final PlanarityHandler planarLayout ; 

private final HashMap<Edge , Double> edgeAngle = new HashMap<Edge , 
Double >() ; 

private final HashMap<Vertex , Edge[]> optimalOrder = new HashMap<Vertex , 
Edge[]>(); 

private final HashMap<Vertex , Edge[]> currentOrder = new HashMap<Vertex , 
Edge[]>(); 

private final HashMap<Vertex , Boolean> correctOrder = new HashMap<Vertex , 
Boolean > () ; 

protected Double order VertexBorder = 3.0d; 

private Color clockwiseOrderColour = Color . yellow ; 

30 private Color anticlockwiseOrderColour = new Color (96, 96, 255); 

31 private Color correctOrderColour = Color . green ; 
private Color errorOrderColour = Color . red ; 
private BasicStroke orderStroke = new BasicStroke( 1.0 f ); 

private Color nonPlanarSubGraphEdgeColour = Color . red ; 

private Color nonPlanarOtherEdgeColour = new Color ( 0, 0, 0, 196 ); 

private BasicStroke nonPlanarSubGraphEdgeStroke = new BasicStroke ( 2.0 f ); 

private BasicStroke nonPlanarOtherEdgeStroke = new BasicStroke ( 1.0 f ); 

public Color get ClockwiseOrder Colour ( ) { return clockwiseOrderColour; } 

public Color get Ant iclockwiseOrder Colour ( ) { return 
anticlockwiseOrderColour ; } 

public Color getErrorOrderColour ( ) { return errorOrderColour; } 

public BasicStroke getOrderStroke ( ) { return orderStroke; } 

public AngleHighlight View ( final VertexLayout layout , final PlanarityHandler 
planarity ) { 

super ( layout ) ; 
planarLayout = planarity ; 
gener at elnit i al D at a ( ) ; 

planarity . addPlanarOrderListener ( this ); 

} 

©Override 
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protected void ge ner at elni t i al D at a ( ) { 

if ( get GraphLayout ( ) . getGraph ( ) . is P lanar ( ) ) { 

for (Edge edge: getGraphLayout (). getGraph (). getEdges () ) 

edgeAngle.put( edge , generateEdgeAngle(edge)); 
for ( Vertex vertex: get GraphLayout (). getGraph (). get Vert ices ( ) ) { 
optimalOrder . put ( vertex, vertex . getEdgeOrder ( ) ); 
currentOrder . put ( vertex, generateCurrentEdgeOrder ( vertex ) ); 
// System . out . p r i nt In ( vertex . toString ( ) + ": " + 

optimalOrder . get ( vertex ). toString ( ) + " — > " + arrayToString ( currentOrder . get ( 
vertex ) ) ) ; 

} 

} 

} 

protected double getEdge Angle ( Edge edge, Vertex vertex ) { 
if ( edge . getFrom ( ) = vertex ) { 

return edgeAngle . get ( edge ) ; 
} else if ( edge . getTo ( ) = vertex ) { 
Double angle = edgeAngle . get ( edge ) ; 
if ( angle != null ) { 
if ( angle < 180 ) 

return angle + 180; 
return angle — 180; 

} 

} 

return Double. NaN; 

} 

protected double generateEdge Angle ( Edge edge ) { 

Point2D . Double from = getGraphLayout (). get VertexLocation ( edge . getFrom ( ) 

); 

Point2D . Double to = getGraphLayout (). get VertexLocation ( edge. getTo () ); 
double x = to.x — from . x ; 
double y = to.y — from.y; 

double angle = Math . toDegrees ( Math . at an2 (— y , x) ); 
if ( angle < ) 
angle += 360; 
return angle ; 

} 

©Override 

protected void p ai n t S et Ver t exF i 1 IS t y le ( Vertex vertex , Graphics2D g2d ) { 
super, p ai n t S et Ver t exF i 1 1 S t y le (vertex , g2d) ; 

if ( get GraphLayout (). getGraph (). isP lanar ( ) &fe correctOrder . get ( vertex ) 
g2d . set C olor ( correctOrderColour ); 

} 

©Override 

protected void paintSetEdgeStyle ( Edge edge, Graphics2D g2d ) { 
if ( planarLayout . isNonPlanarEdge ( edge ) ) { 

g2d . set C olor ( nonPlanarSubGraphEdgeColour ); 
g2d . setStroke ( nonPlanarSubGraphEdgeStroke ); 
} else { 

g2d . set C olor ( nonPlanarOtherEdgeColour ); 
g2d . setStroke ( nonPlanarOtherEdgeStroke ); 

} 

} 

©Override 

public void paint ( Graphics g, boolean paintBackground ) { 
if ( bounds = null ) 
return ; 

Graphics2D g2d = (Graphics2D) g; 
if ( paintBackground ) 
beforePaint( g2d ); 
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115 if ( get GraphLayout ( ) . getGraph ( ) . is P lanar ( ) ) { 

116 g2d . setStroke ( getOrderStroke ( ) ); 

117 for ( Vertex vertex: get GraphLayout (). getGraph (). get Vert i ces ( ) ) { 
us if ( vert ex . s i z e ( ) > 2 ) { 

119 Edge [ ] current = current Order . get ( vertex ); 

120 int ordering = OPJ3EREDJXOCKWISE + ORDEPJ33_AraCIX)CKWISE ; 

121 for ( int i = 0; i < current . length ; i^+ ) { 

122 Edge el = current [ i ] ; 

123 Edge e2 = current [ (i + 1) % current . length ]; 

124 double al = getEdgeAngle ( el , vertex ) ; 

125 double a2 = getEdgeAngle ( e2 , vertex ); 

126 double e = a2 — al ; 

127 if ( e < ) 

128 e += 360; 

129 final Shape s = this . get VertexShape ( vertex ); 

130 Rectangle b = s . getBounds ( ) ; 

131 Shape shape = new Arc2D . Double ( 

132 b.x — order VertexBorder , 

133 b.y — order VertexBorder , 

134 b. width + 2 * order VertexBorder , 

135 b. height + 2 * orderVertexBorder , 

136 al , 

137 e , 

138 Arc2D.PIE 

139 ) ; 

140 if ( e2 = vertex . getClockwiseFrom ( el )) { 

141 g2d . set C olor ( getClockwiseOrderColour ( ) ); 

142 ordering &= ORDEPJ^ JXOCKWISE ; 

143 } else if ( e2 = vertex . get AntiClockwiseFrom ( el ) ) { 

144 g2d . set C olor ( get AnticlockwiseOrderColour ( ) ); 

145 ordering fc= OPJ3EPJ5D_ANTICLOCKWISE ; 

146 } else { 

147 g2d . set C olor ( getErrorOrderColour ( ) ); 

148 ordering fe= ORDEE^JN<X)RRECTLY; 

149 } 

150 g2d . f i 1 1 ( shape ) ; 

151 g2d.draw( shape ); 

152 } 

153 correctOrder . put ( vertex, ordering != ORDEP^JNCOPJtECTLY) ; 

154 } else { 

155 correctOrder . put ( vertex, true); 

156 } 

157 } 

158 } 

159 super, paint ( g, false ); 

160 if ( paintBackground ) 

161 afterPaint( g2d ); 
} 



k;2 



164 protected Edge[] generateCurrentEdgeOrder ( final Vertex vertex ) { 

165 Array List <Edge> connectedEdges = vertex . getConnectedEdges () ; 

166 Edge[] edges = connectedEdges . to Array ( new Edge [ connectedEdges . s i z e ( ) ] ) 

167 Arrays . sort ( edges , new Comparator<Edge>() { 

168 ©Override 

169 public int compare ( final Edge el, final Edge e2) { 

170 double al = getEdgeAngle ( el , vertex ) ; 

171 double a2 = getEdgeAngle ( e2 , vertex ); 

172 if ( al < a2 ) return —1; 

173 if ( al > a2 ) return 1; 

174 return 0; 

175 } 

}); 

177 return edges ; 

178 } 
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iso ©Override 

181 public void handleGraphLayoutChanged ( GraphLayoutEvent event) { 

182 if ( get GraphLayout ( ) . getGraph ( ) . is P lanar ( ) ) { 

183 MovementMap map = event . getMovementMap ( ) ; 

184 final HashSet<Vertex> connected = new HashSet<Vertex >() ; 

185 final HashSet<Edge> edges = new HashSet<Edge > () ; 

186 for ( Vertex vertex: map . get Vert i ces ( ) ) { 

187 for ( Edge edge: vertex . getConnectedEdges ( ) ) { 

188 connected . add ( edge . getOtherEndFrom ( vertex ) ); 

189 } 

loo edges . addAll ( vertex . getConnectedEdges ( ) ); 

191 } 

192 connected . addAll ( map . get Vertices ( ) ); 

193 for (Edge edge: edges) 

194 edgeAngle . put ( edge , generateEdgeAngle ( edge ) ) ; 

195 for ( Vertex vertex : connected ) 

196 currentOrder . put ( vertex, generateCurrentEdgeOrder ( vertex ) ); 

197 / / System . out . println () ; 

198 // for ( Vertex vertex: get GraphLayout (). getGraph (). get Vert i ces ( ) ) 
System . out . p r in t In ( vertex . toString ( ) + ": " + 

optimalOrder . get ( vertex ). toString ( ) + " — > " + arrayToString ( currentOrder . get ( 
vertex ) ) ) ; 
} 

super . handleGraphLayoutChanged ( event ) ; 

} 

204 public static <E> String arrayToString (E [ ] array) { 

205 StringBuffer buffer = new S t r ing B uf f e r ( ) ; 

206 buffer . append( ' [ ' ) ; 

207 for (int i = 0; i < array . length ; i++) { 

208 if ( i > ) 

209 buffer . append ( ", " ); 

210 buffer . append ( ar r ay [ i ] . t o S t r ing ( ) ); 

211 } 

212 buffer, append ( 1 ] ' ) ; 

213 return buf f er . t oS t r ing ( ) ; 



21 1 



} 



216 ©Override 

217 public void handlePlanarOrderChanged ( final PlanarOrderEvent event ) { 

218 if ( planarLayout != event . getPlanarity ( ) ) { 

219 Sy stem. err. println( "AngleHighlightView.handlePlanarOrderChangedO 
incorrect planarity test."); 

220 return ; 

221 } 

222 for ( Vertex vertex: planarLayout . getGraph (). get Vert ices ( ) ) 

223 optimalOrder . put ( vertex, event . getOrder ( vertex ) ); 

224 repaint ( ) ; 

225 } 

226 } 



D.5.2 mgtaylor.display.Arrow 



package mgtaylor . display ; 

import java . awt . geom . Point2D ; 
import java. awt . geom ,Line2D. Double; 

public class Arrow extends Double { 
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*/ 

private static final long serialVersionUID = 4441803674890709608L ; 

public Arrow ( Point2D argO , Point2D argl) { 
super (argO , argl) ; 

} 

public Arrow ( double argO , double argl , double arg2 , double arg3) { 
super (argO , argl , arg2 , arg3) ; 

} 



D . 5 . 3 mgt ay lor . display. DraggableView 



package mgtaylor . display : 

import java . awt . * ; 

import java . awt . event . * ; 

import java. awt . geom . * ; 

import java. util .*; 

import mgtaylor . layout . * ; 

import mgtaylor . graph . * ; 



* Draggable View is an extension of the basic View that allows 

* vertices and edges to be moved from the initial positions by 

* the user through mouse interactions. 

* 

17 * Clicking on a vertex/edge will deselect previous selections and 

is * select the clicked on vertex or edge and the edge's end vertices. 

* Once selected the objects will be highlighted as well as any edges 

* connected to the selected vertices. Dragging while clicked will 

* create ghost copies of the selected objects in the location they 

* have been dragged to , upon release of the mouse the selected 

* objects will be moved by the offset dragged and a GraphDisplayEvent 

* will fire. 

25 * 

26 * Clicking on an empty space and dragging will create a selection 

* box and when the mouse is released the contents of the selection 

* box will be selected. 

* 

* Holding Shift when clicking will cause the previous selections 

* not to be deselected . 

33 * Holding Control when clicking on a vertex/edge will toggle it 's 

34 * selection. 



iauthor Martyn G Taylor 



37 * 

38 */' 



public abstract class DraggableView extends View { 

/* * * / 

private static final long serialVersionUID = 453 1 16469 19 13408845L ; 

protected static final boolean SELECTED = true; 

protected static final boolean DESELECTED = ! SELECTED ; 

private Rectangle clickLocation = null ; 



47 
48 
49 

51 
52 
53 

55 
56 
57 
58 
59 
60 
61 

63 
64 

66 
67 
68 
69 
70 
71 
72 
73 

75 
76 
77 

79 
80 
SI 

83 

84 

85 

86 

87 

88 

89 

91 
92 

94 
95 
96 
97 
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private boolean clickedOnObject = false ; 

// private boolean objectStatus = SELECTED; 

private boolean dragged = false ; 

private final HashSet<Edge> selectedEdges = new HashSet<Edge > () ; 

private final HashSet<Vertex> se 1 ec t e d Ver t i ces = new HashSet<Vertex > () 

private final HashSet<Edge> edgesConnectedToSelected = new HashSet<Edge > () ; 



private BasicStroke selectedEdgeStroke 

private BasicStroke selectedVertexStroke 

private Color selectedEdgeColour 

private Color selected VertexColour 

private Color selected VertexFillColour 

private Color selectedTextColour 

private Font selectedLabelFont 
Font. BOLD, getFont () . getSize () ); 

private BasicStroke connectedEdgeStroke 
private Color connectedEdgeColour 



= new B asicS t roke ( 2 . f ) ; 

= new BasicStroke(2.0f) ; 
Color . black ; 

= Color . black ; 

= Color . white ; 
Color . black ; 

= new Font ( getFont () .getNameQ 



= new BasicStroke (1.5 f) ; 
Color . lightGray ; 



private Color dragColour = Color . blue ; 

private BasicStroke dragStroke = new BasicStroke ( 



l.Of , 

BasicStroke ,CAP_ROUND, 
BasicStroke ,J0IN_R0UND, 
10. Of , 

new float [] { 5. Of , 5.0 f 

O.Of); 



Line width 

// Line end cap style 
// Line join style 

// Miter Limit 

// Dash Pattern 

// Dash phase 



public Draggable View ( VertexLayout layout) { 
super ( layout ) ; 

} 

public Draggable View ( View view) { 
super ( view ) ; 

} 

public BasicStroke get Select edEdge St roke ( ) 
selectedEdgeStroke ; } 

public BasicStroke get Select ed Vert exSt roke ( ) 
selectedVertexStroke ; } 
public Color get Select edEdgeColour ( ) 
selectedEdgeColour ; } 

public Color get Select ed Vert exC olour ( ) 
selectedVertexColour ; } 

public Color get S elect ed Ver t exFillC olour ( ) 

selected VertexFillColour ; } 

public Color getSelectedTextColour () 

selectedTextColour ; } 

public Font getSelectedFont () 

selectedLabelFont ; } 

public BasicStroke getConnectedEdgeStroke ( ) 
connectedEdgeStroke ; } 

public Color getConnectedEdgeColour ( ) 
connectedEdgeColour ; } 



public void set S elect edEdgeS t roke ( B asicSt roke stroke) 
selectedEdgeStroke = stroke ; } 

public void se t S elect ed Vert exSt roke ( B asicSt roke stroke) 
selectedVertexStroke = stroke ; } 

public void setSelectedEdgeColour ( Color colour) 
selectedEdgeColour = colour ; } 

public void setSelectedVertexColour ( Color colour) 
selectedVertexColour = colour ; } 



{ return 
{ return 
{ return 
{ return 

{ return 
{ return 
{ return 



{ return 
{ return 

{ 

{ 

{ 
{ 
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108 
109 
110 
111 
112 
113 
111 
115 
116 
117 
US 
119 
120 
121 
122 
123 
124 

126 
127 
128 
129 

131 
132 
133 
134 

136 
137 
138 
139 
140 
111 
142 
113 
144 
145 
146 

148 
149 
150 
151 



public void se t S e lect e d Vert exF il 1C olour ( Color colour) 
selected VertexFillColour = colour ; } 
public void setSelectedTextColour ( Color colour) 
selectedTextColour = colour ; } 
public void setSelectedFont ( Font font) 
= font ; } 

public void setSelectedFont ( String name, int style 
setSelectedFont (new Font ( name, style, size )); } 

public void c le ar S ele c t ed ( ) 

se lec t e d V er t i c e s . clear () ; selectedEdges . clear () ; 
edgesConnectedToSelected . clear () ; } 
public boolean i s S e 1 e c t e d ( Edge edge) 
selectedEdges . contains ( edge ) ; } 
public boolean isConnected ( Edge edge) 
edgesConnectedToSelected . contains (edge) ; } 
public boolean i s S e 1 e ct e d ( Vertex node) 
selected Vert ices . contains ( node ) ; } 



{ 
{ 

{ selectedLabelFont 
int size) { 

{ 

{ return 
{ return 
{ return 



public void add Select ed Vert ices ( Vertex vertex) { 
if ( !isSelected( vertex ) ) { 
se lec t e d Vert i ce s .add(vertex) ; 

for ( Edge edge: vertex . getConnectedEdges ( ) ) { 

if ( edgesConnectedToSelected . contains ( edge ) ) { 
edgesConnectedToSelected . remove ( edge ); 
selectedEdges . add ( edge ); 
} else { 

edgesConnectedToSelected . add ( edge ); 



} 



} 



public 
for 

} 



void addSelectedVertices ( Collection <Vertex> vertices) 
( Vertex vertex: vertices ) 
addSelectedVertices ( vertex ); 



public void addSelectedEdges ( Edge edge) { 
addSelectedVertices ( edge . getFrom ( ) ); 
addSelectedVertices ( edge.getToQ ); 

} 

public void addSelectedEdges ( Collection <Edge> edges) { 
for ( Edge edge : edges ) 

addSelectedEdges ( edge ); 

} 

public void removeSelectedVertices ( Vertex vertex) { 
sele ct edVe r t i c e s . remove ( vertex ); 
for ( Edge edge: vertex . getConnectedEdges ( ) ) { 
if ( selectedEdges . contains ( edge ) ) { 
edgesConnectedToSelected . add ( edge ); 
selectedEdges . remove ( edge ); 
} else { 

edgesConnectedToSelected . remove ( edge ); 

} 



} 



} 



public void removeSelectedVertices ( Collection <Vertex> vertices) 
for ( Vertex vertex: vertices ) 

removeSelectedVertices ( vertex ); 

} 

public void removeSelectedEdges ( Edge edge) { 
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154 
155 
156 

158 
150 
160 
161 

163 
164 
165 
166 
167 
16* 
169 
170 
171 
172 



100 
200 
201 
202 
203 
204 
205 
206 
207 
208 
209 
210 
211 
212 
213 
214 
215 
216 
217 
218 



removeSelectedVertices ( edge . getFrom ( ) ); 
removeSelectedVertices ( edge . getTo ( ) ); 

} 

public void removeSelectedEdges ( Collection<Edge> edges) { 
for ( Edge edge : edges ) 

removeSelectedEdges ( edge ); 

} 

©Override 

protected void paint S et Vert exStyle ( Vertex vertex , Graphics2D g2d ) { 
if ( isSelected( vertex ) ) { 

g2d.setStroke(getSelectedEdgeStroke()); 
g2d. setColor(getSelectedVertexColour () ) ; 
} else { 

g2d .setStroke(getEdgeStroke()); 
g2d.setColor(getVertexColour()) ; 

} 

} 



Graphics2D g2d ) { 



17-1 


©Override 


175 


protected 


176 


if 


( i 


177 




g2d 


178 




g2d 


170 


} 


else 


180 




g2d 


181 




g2d 


182 


} 




183 


} 




185 


©Override 


186 


protected 


187 


if 


( i 


188 




g2d 


189 




g2d 


100 


} 


else 


191 




g2d 


102 




g2d 


193 


} 


else 


101 




g2d 


195 




g2d 


196 


} 




197 


} 





void paintSetEdgeStyle ( Edge edge, Graphics2D g2d ) { 
Selected( edge ) ) { 

setStroke (getSelectedEdgeStroke () ) ; 
setColor(getSelectedEdgeColour()) ; 
if ( isConnected( edge )) { 



{ 

setStroke (getEdgeStroke () ) 
setColor(getEdgeColour() ) ; 



©Override 

public void paint ( Graphics g) { 
super . paint (g) ; 

if ( ! clickedOnObject &fe clickLocation != null ) { 
Graphics2D g2d = (Graphics2D) g; 
g2d . setStroke ( dragStroke ); 
g2d . set C olor ( dragColour ); 
int x , y , w, h ; 

if ( clickLocation . width >= 0) { 

x = clickLocation . x ; 

w = clickLocation . width ; 
} else { 

x = clickLocation . x + clickLocation . width ; 
w = —clickLocation. width; 

} 

if (clickLocation . height >= ) { 

y = clickLocation . y ; 

h = c 1 ickL oc at ion . height ; 
} else { 

y = clickLocation . y + clickLocation . height ; 
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219 h = — c li ckLocat ion . height 



220 
221 



222 } 

223 } 



} 

g2d . drawRect (x , y, w, h) 



239 
2-10 



225 ©Override 

226 public void mousePressed ( final MouseEvent event ) { 

227 if (bounds = null || ! bounds . contains ( event . get Point ( ) )) 

228 return ; 

clickLocation = new Rectangle( event. getPointQ.x, event. getPointQ.y, 0, 

o ); 

231 dragged = false ; 

232 clickedOnObject = false ; 

233 // objectStatus = DESELECTED; 

235 final int modifiers = event . get Mod if ier s () ; 

236 final boolean Ctrl = ( modifiers & InputEvent .CTRL_MASK ) != 0; 

237 final boolean shift = ( modifiers & InputEvent .SHTFT_MASK ) != 0; 

238 if (! Ctrl &fe ! shift ) { 
clearSelected () ; 

} 

241 final Vertex vertex = getVertexContaining ( event . getPoint ( ) ); 

242 if ( vertex != null ) { 

243 if ( Ctrl && isSelected ( vertex )) { 

244 removeSelectedVertices( vertex ); 

245 } else { 

246 clickedOnObject = true; 

247 addSelectedVertices( vertex ); 

248 // objectStatus = SELECTED; 

249 } 

250 } else { 

251 final Edge edge = getEdgeContaining ( event . getPoint ( ) ); 
if ( edge != null ) { 

253 if ( ctrl && isSelected( edge )) { 

254 removeSelectedEdges ( edge ) ; 
} else { 

256 clickedOnObject = true; 

257 addSelectedEdges ( edge ) ; 

258 // objectStatus = SELECTED; 

259 } 
} 

} 

262 repaint ( ) ; 

263 } 

265 ©Override 

266 public void mouseReleased ( MouseEvent event) { 

267 if ( clickLocation = null ) 

268 return ; 

269 if ( clickedOnObject ) { 

270 if ( dragged ) { 

271 final double w = c 1 i ckL ocat ion . getWidth ( ) / bounds . getWidth ( ) * 
100. Od; 

final double h = c 1 i ckLocat ion . get Height ( ) / bounds . getHeight ( ) * 
100. Od; 

273 Point2D . Double offset = new Point2D . Double ( w, h ) ; 

274 final HashSet<Vertex> vertices = new HashSet<Vertex >( 
selected Vertices ) ; 

ConstantMovementMap map = new ConstantMovementMap ( getGraphLayout ( ) 
vertices , offset ); 

276 clickedOnObject = false ; 

277 clickLocation = null; 

278 dragged = false ; 



260 
261 
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279 
280 
281 
282 
283 
284 
285 
286 
287 
288 
289 
290 
291 
292 
293 
294 
295 
296 
297 
298 
299 
300 
301 
302 
303 
304 
305 
306 
307 
308 
309 
310 
311 
312 
313 



} 



setOffsetMovementMap ( null ); 
getGraphLayout ( ) . processMovement (map) 



) { 



+ vertex . toString ( ) ) 



vert ex . to St ring ( ) ) 



} else { 

HashSet<Vertex> vertices = get VerticesWithin ( clickLocation 
HashSet<Edge> edges = getEdgesWithin ( clickLocation ) 
if ( (event . ge t Mod if ier s () & InputEvent .CTRL_MASK) ! = 
if ( vertices != null ) 

for (Vertex vertex: vertices) 
if (isSelected( vertex ) ) { 

removeSelectedVertices (vertex) 
// System . err . pr i nt 1 n ( "Removing: 

} else { 

addSelectedVertices ( vertex ) ; 
// System . err . pr i nt 1 n ( "Adding: " 

} 

if ( edges != null ) 

for (Edge edge: edges) 

if (isSelected( edge ) ) { 
removeSelectedEdges ( edge ) ; 

// System . err . pr i nt 1 n ( "Removing: 

} else { 

addSelectedEdges ( edge ) ; 
// System . err . println ( "Adding: " 

} 

} else { 

addSelectedVertices ( vertices ); 
addSelectedEdges ( edges ) ; 

} 

clickedOnObject = false ; 
clickLocation = null; 
dragged = false ; 
repaint ( ) ; 



+ edge . toString ( ) ) 



edge . toString ( ) ); 



315 
316 
317 
318 
319 
320 
321 
322 
323 
324 
325 

326 
327 

328 
329 
330 
331 
332 



©Override 

public void mouseDragged ( MouseEvent event) { 



if 



null ) 



clickLocation . : 
- clickLocation 



y I 



( clickLocation 
return ; 
dragged = true ; 
Point p = event . getPoint () 
clickLocation . width = p.x 
clickLocation . height = p.y 
if ( clickedOnObject ) { 

final double w = clickLocation 
final double h = clickLocation 
100. Od; 

Point2D . Double offset = new Point2D . Double ( w, h ); 

ConstantMovementMap map = new ConstantMovementMap ( getGraphLayout ( ) 
selected Vertices , offset ) ; 
setOffsetMovementMap (map) ; 

} 

repaint ( ) ; 



getWidthQ / bounds . getWidth ( ) * 100. Od: 
getHeightQ / bounds . get Height ( ) * 



D.5.4 mgtaylor. display. JIntegerTextField 



package mgtaylor . display : 
import java . awt . event . * ; 
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import j avax . swing . JTextField ; 
import j avax . swing . text . Document ; 

public class JIntegerTextField extends JTextField { 
private int maximum = 9999; 

/ * * */ 

private static final long serial VersionUID = 6095737152358650784L ; 

public JIntegerTextField ( final String text) { 

super ( Integer . toString ( Integer . parselnt ( text ) ) ); 

} 

public JIntegerTextField ( final int columns) { 
super ( columns ) ; 

} 

public JIntegerTextField ( final String text , final int columns) { 
super ( Integer. toString ( Integer. parselnt ( text ) ), columns ); 

} 

public JIntegerTextField ( final Document doc, final String text , final int 
columns) { 

super( doc , Integer . toString ( Integer . parselnt ( text ) ) , columns ) ; 

} 

public void processKey Event ( final KeyEvent event ) { 
final char c = event . getKeyChar () ; 

if ( (Character . isDigit (c) && ! event . isAltDown () ) ) { 

super . processKey Event ( event ) ; 

if ( get Value () > maximum ) 
setValue ( maximum ) ; 
} else if ( ( c = 8 ) || ( c = 10 ) || ( c = 127 ) || ( c = 65535 ) ) { 

/ * 

* 8: Backspace 

* 10: Enter 

* 127: Delete 

* 65535: Direction Keys 

*/ 

super . processKey Event ( event ) ; 
} else { 

System . err . pr i nt 1 n ( (int) c ); 
event . consume () ; 

} 

} 

public int get Value () { 
try { 

return Integer . parselnt ( getTextQ ); 
} catch ( NumberFormatException e) { 
return 0; 

} 

} 

public void setValue( int value ) { setText ( Integer . toString ( 
Math . min ( maximum , value) ) ); } 

public void setMaximum ( int value ) { maximum = value; } 



D . 5 . 5 mgt ay lor . display. Planar ity Handler 



f 

i package mgtaylor . display 
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import java . util . HashSet ; 

import mgtaylor . layout . VertexLayout ; 
import mgtaylor . planarity . event . * ; 

import mgtaylor . graph . * ; 

public class PlanarityHandler implements PlanarOrderHandler { 
private final Graph graph; 

private final HashSet<PlanarOrderListener > orderListeners = ne 

HashSet<PlanarOrderListener >() ; 

public PlanarityHandler (Graph graph) { 
this. graph = graph; 

} 

public Planarity Handler ( VertexLayout layout) { 
this ( layout . getGraph () ) ; 

} 

public Graph getGraph () { return graph; } 

public boolean isNonPlanarEdge (Edge edge) { return 

edge . hasPlanarityConflict () ; } 

©Override 

28 public void addPlanarOrderListener ( PlanarOrderListener listener) { 

29 orderListeners . add ( listener ); 
} 

32 ©Override 

33 public void processPlanarOrderEvent ( PlanarOrderEvent event) { 
for ( PlanarOrderListener listener: orderListeners ) 

1 i s t e n e r . handlePlanarOrder Changed ( event ); 

} 

©Override 

public void removePlanarOrderListener ( PlanarOrderListener listener) { 
orderListeners . remove ( listener ); 

} 



D . 5 . 6 mgt ay lor . display. Planar ity Viewer 



package 


mgtaylor 


. display ; 


import 


java . awt . 


* ; 




import 


j ava . awt . 


event . * 




import 


j avax . swing . * ; 




import 


mgtaylor . 


display 


. data . * ; 


import 


mgtaylor . 


layout . 


* j 


import 


mgtaylor . 


graph . * 
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raphTypes 
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import mgtaylor . graph . graphTypes . TriangularPrismMaximalPlanarGraph ; 
public class Planarity Viewer extends JFrame { 

/* * * / 

private static final long serialVersionUID = - 653471 16 16529357001L ; 



public 
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public 

}\nedg 

(C,F) , 

public 

}\nedg 

(C,F) , 

public 

}\nedg 
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public 
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public 

}\nedg 

(E,F)\ 

public 

}\nedg 

(D,A)\ 
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(F,G) 
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es \n{\ 
\n (D 
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\n (D 
stati 
es\n{\ 
\n (D 
stat i 
es\n{\ 
\n (C 
stat i 
es\n{\ 
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stati 
es \n{\ 
n}" ; 



final 
, H , N , 
(G,H) , 
(0,E) , 
final 
(A , B) 
E), (D, 
c final 
n (A , B) 
,E), (D, 
c final 
(A , B) 
E)\n}" ; 
final 
(A , B) 
A)\n}" ; 
final 
(A , B) 

c final 
(A , B) 



String GRAPH_HOPTAR = 11 nodes \n { A, B, C, D, E, F, G, 
0, P }\nedges\n{\n (A , B) , (B,C), (C,D), (D , E) , (D , G) , 
(H,F), (H,I), (I, J), (J,K), (L , A) , (K , L) , (L , M) , (N,J), 
(0,M), (N,0), (B,P), (C,P), (K,P)\n}" ; 

String GRAPH_TEST1 = "nodes\n { A, B, C, D, E, F, G 

, (A,C), (A,D),\n ( A , E) , (A , F) , (A,G),\n (B,C), (C,D), 

G), (E,F),\n (E,G)\n}" ; 

String GRAPH_TEST2 = "nodes\n { A, B, C, D, E, F, G , H 

, (A,C), (A,D),\n ( A , E) , (A , F) , (A,G),\n (B,C), (C,D), 

G) , (E,F),\n (E,G), (C,H), (H,A)\n}"; 

String GRAPH_K5 = " nodes \n { A, B, C, D, E 

, (A,C), (A , D) , (A,E),\n (B,C), (B,D), (B,E),\n (C,D), 

String GRAPH_K5_2 = "nodes\n { A, B, C, D, E 

, (B,C), (C,D), (D,E),\n (E , A) , (E,B), (E,C),\n (D , A) , 

String GRAPH_K3_3 = "nodes\n { A, B, C, D, E, F 

, (A , D) , (A,F),\n (C,B), (C,D), (C,F),\n (E,B), (E,D) , 

String GRAPH_K3_3_2 = " nodes \n {A, B, C, D, E, F 

, (B,C), (C,D),\n (D,E), (E,F), (F,A),\n (F,C), (E,B), 



public static final String 
H, I }\nedges\n{\n (0,A), 
(F,G) , (G , A) ,\n (F,H) , (H 
public static final String 
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H }\nedges\n{\n (0,A), (A 
(G,A),\n (F , H) , (H,B), (H 
public static final String 
H, I }\nedges\n{\n (0,A), 
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(A , B) , (B 
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GRAPH_K3 
), (B,C), (C,D), (D , Q ) An (D,E) 
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,B), (B,C)~ 
,C),\n (E 
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3c = 
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,B)}' 
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, (I, 
3e = 
,C) , 
An 
3f = 
(C, 
,B)}' 
3g = 
, (C, 
,B)}' 



"nodes\n { 0, A, B 
0) ,\n (C,D) , (D,E) 



C , D , E , F , G 
(E,F), (F,G), 

C , D , E , F , G , 
(E,F), (F , G) , 



"nodes\n { 0, A, B 
(C,D) , (D,0) An (D 
E) An (G,C)}"; 
"nodes\n { 0, A, B 
(C,D) , (D,0) An (D 
(E,I), (I, A), (I,B)} 
"nodes\n { 0, A, B 
D) , (D,0) An (D,E) 

"nodes\n { 0, A, B 
D) , (D,0) An (D,E) 



C , D , E , F , G , 
E) , (E,F), 



C , D , E , F , G , 
E) , (E,F), 

C , D , E , F , G , 
E) , (E,F), 

C , D , E , F , G , 
(E , F) , (F , G) , 

C , D , E , F , G , 
(E,F), (F , G) , 



private static final String DEFAULT_GPAPH_TEXT = GRAPHHOPTAR ; //GRAPH_K3_3g; 



private final JTextArea data 

private final JTabbedPane panes 

private final JPanel generatorPanel 

private final JPanel inputPanel 

private final DisplayPanel viewPanel 

private final DisplayPanel dataPanel 

private final DisplayPanel segmentPanel 

private final DisplayPanel permutationPanel = new DisplayPanel () ; 

private final DisplayPanel blockPanel = new DisplayPanel () ; 



= new JTextArea ( DEFAULT_GPAPH_TEXT ) 
= new JTabbedPane ( ) ; 
= cr eat eGener at orP anel ( ) ; 
= createlnput Panel () ; 
= new Display P anel ( ) ; 
= new DisplayPanel () ; 

= new DisplayPanel () ; 



private Graph graph = null ; 
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65 
66 



SO 
81 



84 
85 



88 
89 



96 
9 7 



100 
101 
102 
103 
101 
105 



108 
109 
110 
111 

112 
113 



public Planarity Viewer ( ) { 
super ( ) ; 

setLayout (new BorderLayout ( ) ) ; 
try { 

UIManager .setLookAndFeel(" com. sun.jav a. swing, pi af. windows. WindowsLookAndF 

} catch (Exception exception) {} 



3el " ) 



panes . addTab ( 
panes . addTab ( 
panes . addTab ( 
panes . addTab ( 
panes . addTab ( 
panes . addTab ( 
JSplitPane split 
panes ) ; 

split . setResizeWeight (0.5) 
getContentPane () . add( split 



Generate", generatorPanel ) ; 
Input", inputPanel); 
Vertices" , dataPanel) ; 
Segments" , segmentPanel ) ; 
Permutations" , permutationPanel ) ; 
Blocks", blockPanel); 

new JSplitPane ( JSplitPane . HORIZONTAL_SPLIT , viewPanel , 



BorderLayout .CENTER) ; 



} 



setDefaultCloseOperation ( JFrame.EXIT_ON_CLOSE) 
pack ( ) ; 

setVisible (true) ; 

panes . setSelectedComponent ( inputPanel ); 



public Graph getGraphQ { 
return graph ; 

} 

public void setGraph( final Graph graph ) { 
setGraph( graph , ) ; 

} 

public void setGraph( final Graph graph, final int root ) { 
this. graph = graph; 
if ( graph != null ) { 

final VertexLayout layout ; 

if ( graph instanceof PlanarWheelGraph || graph instanceof 
PlanarMultiWheelGraph ) 

layout = new PlanarW heelLayout ( graph ); 
else if ( graph instanceof TriangularPrismMaximalPlanarGraph ) 

layout = new TriangularPrismMaximalPlanarLayout ( graph ) ; 
else if ( graph instanceof OrderedFaceTrisectionGraph ) 

layout = new Ordered VertexLayout ( graph ); 
else if ( graph instanceof PermutableFlippableGraph ) 

layout = new PermutableFlippableLayout ( graph ); 
else 

layout = new RandomVertexLayout ( graph ); 
PlanarityHandler planarity = new PlanarityHandler ( layout ); 
final j ava . u t i 1 . Array List <Vertex> vertices = graph . get Vert ic es () ; 
final int size = ve r t i c es . s i z e ( ) ; 

graph . timePlanarityTest ( v e r t i ce s . ge t ( Math.max( Math.min( root, size — 
1), 0) ) ); 

System . out . println ( graph . getSegments () . getHead () . toIndentedString ( " " , 

" " ) ); 

viewPanel . setPanel ( new AngleHighlightView ( layout, planarity ) ); 
dataPanel . setPanel ( new VertexDataView ( layout, planarity ) ); 
segmentPanel . setPanel ( new SegmentDataView ( layout, planarity ) ); 
permutationPanel . setPanel ( new PermutationDataView ( layout , planarity ) 

); 

blockPanel . setPanel ( new BlockDataView ( layout, planarity ) ); 
panes . setSelectedComponent ( permutationPanel ) ; 
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114 if ( viewPanel . i s V i s i b 1 e ( ) ) 

115 viewPanel . repaint () ; 
} 



116 



117 } 



119 
120 



public JPanel cr eat eGener at orP anel ( ) { 
final JPanel panel = new JPanel () ; 



121 panel . setLayout ( new GridBagLayout ( ) ); 

123 final JLabel typeLabel = new JLabel( "Type" ); 

124 final JLabel verticesLabel = new JLabel( "Vertices" ); 

125 final JLabel edgesLabel = new JLabel( "Edges" ); 

126 final JLabel createLabel = new JLabel( "Create..." ); 

final JLabel maxPlanarLabel = new JLabel ( "Maximum Planar:" 

); 

final JIntegerTextField maxPlanarVertices = new JIntegerTextField ( "25", 4 

); 

final JButton createMaxPlanar = new JButton( "Create Max Planar 

Graph ..."); 

131 createMaxPlanar . add ActionListener (new ActionListener ( ) { 

132 ©Override 

133 public void actionPerformed ( ActionEvent argO) { 

134 graph = new RandomMaximalPlanarGraphGenerator ( 
maxPlanarVertices . getValue () ) . generateGraph( 
maxPlanar Vertices . get Value ( ) ); 

135 graph . s e 1 1 d e n t i fi e r (" Random Graph"); 

136 setGraph( graph ); 

137 data.setText(graph.toString()); 

138 } 

139 }); 

final JLabel orderedPlanarLabel = new JLabel( "Ordered 

Maximum Planar : " ) ; 

final JIntegerTextField orderedPlanarVertices = new JIntegerTextField ( 
"25" , 4 ) ; 

final JButton createOrderedPlanar = new JButton( "Create 

Ordered Planar Graph ..."); 

144 createOrderedPlanar . addActionListener (new ActionListener ( ) { 

145 ©Override 

146 public void actionPerformed ( ActionEvent argO) { 

147 graph = new OrderedFaceTrisectionGraph ( 
orderedPlanarVertices . getValue () ) ; 

148 graph . s et I d e n t i fi e r (" Order ed Maximal Planar Graph"); 

149 setGraph( graph ) ; 

150 data . set Text ( graph . to St ring ()) ; 

151 } 

152 }); 

154 final JLabel triPrismLabel = new JLabel( "Triangualr Prism:" ); 

155 final JIntegerTextField t r i P r ism Vert ices = new JIntegerTextField ( "25", 4 

); 

final JButton createTriPrismPlanar = new JButton( "Create Tri . 

Prism Max Planar Graph ..."); 

157 createTriPrismPlanar . addActionListener (new ActionListener ( ) { 

158 ©Override 

159 public void actionPerformed ( ActionEvent argO) { 

160 graph = new TriangularPrismMaximalPlanarGraph ( 
t r i P r ism Vert ic es . get Value ( ) ); 

161 graph . s et I d e n t i fi e r (" Random Triangular Prism Graph"); 

162 setGraph( graph ) ; 

163 data.setText(graph.toString()); 
} 

}); 



164 
165 
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final JLabel planarWheelLabel = new JLabel( "Planar Wheel Graph:' 

); 

final JIntegerTextField planarWheelVertices = new JIntegerTextField ( 
"25" , 4 ) ; 

final JButton createPlanarWheel = new JButton( "Create 

Graph ..."); 

170 createPlanarWheel . add ActionListener (new ActionListener ( ) { 

171 ©Override 

172 public void actionPerformed ( ActionEvent argO) { 

173 graph = new PlanarWheelGraph ( planar Wheel Vert ices . get Value ( ) ); 

174 graph . s e 1 1 d e n t i fi e r (" Random Graph"); 

175 setGraph( graph ); 

176 data.setText(graph.toString()); 
} 

}); 



177 
178 



final JLabel planarMultiWheelLabel = new JLabel( "Planar 

Wheel Graph : " ) ; 

final JIntegerTextField planarMultiWheelVertices = new 
JIntegerTextField ( "25", 4 ); 

final JIntegerTextField planarMultiWheelWheels = new 

JIntegerTextField ( "4", 4 ); 

183 final JCheckBox planarMultiWheelOuterCycle = new JCheckBoxQ; 

184 final JButton createMultiPlanarWheel = new JButton( "Create 
Graph ..."); 

185 createMultiPlanarWheel . add ActionListener (new Act ionLis t ener ( ) { 

186 ©Override 

187 public void actionPerformed ( ActionEvent argO) { 

188 graph = new PlanarMultiWheelGraph ( 

189 planarMultiWheelVertices . getValue ( ) , 
loo planarMultiWheelWheels . get Value ( ) , 

191 planarMultiWheelOuterCycle . isSelected () 

192 ) ; 

193 graph . s e 1 1 d e n t i fi e r (" Random Graph"); 

194 setGraph( graph ) ; 

195 data.setText(graph.toString()); 

196 } 

197 }); 

199 final JLabel biconnectedLabel = new JLabel( " Biconnected : " ); 

200 final JIntegerTextField biconnectedVertices = new JIntegerTextField (" 5 " , 

4); 

201 final JIntegerTextField biconnectedEdges = new J Integer Text F ield (" 9 " , 5) 

202 final JButton createBiconnected = new JButton ( "Create 
Biconnected Graph ..."); 

203 createBiconnected . add ActionListener (new Act ionL is t ener ( ) { 

204 ©Override 

205 public void actionPerformed ( ActionEvent argO) { 

206 int v = biconnectedVertices . getValue () ; 

207 int e = biconnectedEdges . get Value () ; 

208 Graph g = new RandomMaximalPlanarGraphGenerator ( v ) . generateGraph ( 

v ); 

graph = new ReduceableBiconnectedGraphGenerator ( g, 
g . get Vertices (). get ( ) ). generateGraph ( g.edgeSizeQ — e ); 

210 graph . s e 1 1 d e n t i fi e r (" Random Graph"); 

211 setGraph( graph ) ; 

212 data . set Text ( graph . to St ring ()) ; 

213 } 

214 }); 

216 /* final JLabel snakeLabel = new JLabel ( "Snake:" ) ; 

217 final JIntegerTextField snake Vertices = new JIntegerTextField (" 5 " , 4); 

218 final JIntegerTextField snakeRoot = new JIntegerTextField (" 5 " , 4); 

219 final JButton createSnake = new JButton( "Create Snake 
Graph ..."); 
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220 
221 
222 
223 
224 
225 
226 
227 
228 
229 
230 



createSnake . addActionListener (new ActionListener() { 
©Override 

public void actionPerformed(ActionEvent argO) { 
final int v = snakeVertices.getValue(); 
graph = new mgtaylor . graph . graphTypes . SnakeGraph ( v) ; 
graph, setldentifier ( " Snake Graph 11 ) ; 
set Graph ( graph , snake Root . getValueQ — 1 ); 
data . setText (graph . toString () ) ; 



}) 



} 



*/ 



232 
233 
234 
235 

236 
237 
238 
239 
2-10 
241 
212 
213 
244 
245 

247 
248 
249 



final JLabel pfLabel = new JLabel( "Permutable Flippable:" ); 

final JIntegerTextField pfVertices = new J Int egerText Field ( " 5 " , 4); 

final JIntegerTextField pfRoot = new JIntegerTextField (" 1 " , 4); 

final JButton createPF = new JButton( "Create Perm. Flip. 

Graph ..."); 

createPF . addActionListener (new ActionListener ( ) { 
©Override 

public void actionPerformed ( ActionEvent argO) { 
final int v = pfVert ices . get Value () ; 

graph = new mgt ay lor . graph . graphTypes . Permut ableFlippableGr aph ( v ) ; 
graph . s e 1 1 d e n t i fi e r (" Permutable Flippable Graph"); 
setGraph( graph, pfRoot . get Value ( ) — 1 ); 
data.setText(graph.toString()) ; 

} 



}); 
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createPF , 


getGBC (4, y+ 


+, 


1 . 


1 


0.0 , 


278 


// 

0.0)) 


panel 


. add 


snakeLabel , 


getGBC (0, y, 




1 . 


1 


0.0 , 


279 


// 

0.0)) 


panel 


. add 


snake Vertices , 


getGBC ( 1 , y , 




1 . 


1 


1.0 , 


280 


// 


panel 


. add 


snakeRoot , 


getGBC ( 2 , y , 


1 , 


1 . 


1 


, 0.0) ) 


281 


// 

0.0)) 


panel 


. add 


createSnake , 


getGBC (4, y+ 


+, 


1 . 


1 


0.0 , 



2*2 
283 

285 
286 
287 

289 
290 
291 
2 92 
293 
294 
295 

297 
298 
299 
300 
301 

302 
303 
304 
305 
306 

307 
308 
309 
310 
311 
312 
313 
314 



} 



return panel 



public JPanel createlnput Panel ( ) { 

final JPanel panel = new JPanel () ; 
panel . setLayout (new GridBagLayout () ) ; 

final JButton load = new JButton ( " Load " ) ; 
load . add ActionListener (new Ac t ionLis t ener ( ) { 
©Override 

public void actionPerformed ( ActionEvent argO) { 
setGraph( new Graph ( data . getText () ) ); 

} 

}); 

final JButton speedTest = new JButton (" Speed Test"); 
speedTest . add ActionListener (new Ac t ionLis t ener ( ) { 
©Override 

public void actionPerformed ( ActionEvent argO) { 

int [] vertexNumbers = {5000, 1000}; // 500, 200, 100, 75, 50, 
30, 20, 10 

for (int j : vertexNumbers) { 
System .out.println(j); 
System .out.printlnQ; 
for (int i = 0; i < 1000; i++) { 
graph = new 

RandomMaximalPlanarGraphGenerator ( j ) . generateGraph ( j ) ; 
graph . setldentifier ( Integer . toString ( i ) ) ; 
graph. timePlanarityTestQ ; 
graph = null ; 

if (i % (5000/j) = 0) System. gc(); 

} 



40 . 



}) 



} 



} 
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panel . add(new JScrollPane ( data ) , getGBC(0, 0, 2, 1, 1.0, 1-0)); 
panel. add( load , getGBC(0, 1, 1, 1, 1.0, 0.0)); 

panel. add( speedTest , getGBC(l, 1, 1, 1, 1.0, 0.0)); 

return panel ; 

} 

public static GridBagConstraints getGBC(int x, int y, int w, int h , double 
wx, double wy) { 

GridBagConstraints gbc = new GridBagConstraints ( ) ; 
gbc . gridx = x ; 
gbc . gridy = y ; 
gbc . ipadx = ; 
gbc . ipady = ; 

gbc .insets = new Insets ( 2 , 2, 2, 2); 
gbc . weightx = wx; 
gbc . weighty = wy ; 
gbc . gridwidth = w; 
gbc . gridheight = h; 

gbc. fill = GridBagConstraints .BOTH; 
gbc. anchor = GridBagConstraints .CENTER; 
return gbc ; 



h 

* (Siparam args 

* / 

public static void main ( St ring [ ] args) { 
new Planarity Viewer ( ) ; 

} 

public static class DisplayPanel extends JPanel { 

/ * * * / 

private static final long serialVersionUID = - 1 722530348771628881L ; 
private JPanel panel = null ; 

public DisplayPanel ( ) { 
super () ; 

setLayout ( new BorderLayout ( ) ); 
setMinimumSize ( new Dimension ( 400, 400 )); 
se t P refer re d S i z e ( new Dimension( 400, 400 )); 

} 

public void setPanel( JPanel panel ) { 
if ( this . panel != null ) { 
remove(this . panel) ; 

if ( this . panel instanceof KeyListener ) 

removeKeyListener ( (KeyListener) this . panel ); 

} 

this . panel = panel ; 

if ( panel != null ) { 

add( panel, BorderLayout .CENTER) ; 

if ( this . panel instanceof KeyListener ) 
addKeyListener ( (KeyListener) panel ); 

} 

} 



D.5.7 mgtaylor. display. View 
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import 


j ava . awt . 


* j 


import 


java . awt . 


event . * ; 


import 


j ava . awt . 


font . * ; 


import 


j ava . awt . 


geom . * ; 


import 


j ava . u t i ] 


■ * j 


import 


j avax . swing . * ; 


import 


mgtaylor . 


layout . * ; 


import 


mgtaylor . 


layout . event . * 


import 


mgtaylor . 


graph . * ; 



View is a layer of abstraction between a component displaying the 
visualisation of the graph and a graph data structure. 

The view maintains a set of co-ordinates for each vertex (With 
values O.Od to 100. Od for the x and y co-ordinates) , which are 
independent of the co-ordinate system used by the displaying 
component. When a component is displayed the vertex co-ordinates 
are converted to screen locations , meaning that operations can be 
performed on the view irrespective of the changes to the actual 
output area . 

Output region is a square canvas of maximum possible size for the 
displaying component. This prevents distortion due to scaling on a 
single axis . 



Pressing the keys Ctrl- 
Pressing the keys Ctrl- 

Qauthor Martyn G Taylor 



-z will undo vertex movements, 
•y will redo vertex movements. 



*/ 

public abstract class View 
extends JPanel 

implements ComponentListener , GraphLayoutListener , 

MouseListener , MouseMotionListener , KeyListener { 

1***1 

private static final long serialVersionUID = -6879984664846100587L ; 



private static final 
private static final 
private static final 



Dimension MINIMUM_SIZE 
Dimension PREFERRED_SIZE 
Dimension MAXIMUM SIZE 



= new Dimension ( 100, 100 ) 
= new Dimension ( 100, 100 ): 
= null; 



private final VertexLayout layout ; 
private final View view; 

private final HashMap<Vertex , Shape> 
HashMap<Vertex , Shape>(); 
private final HashMap<Edge , Shape> 
HashMap<Edge , Shape > () ; 
private final HashMap<Vertex , Shape> 
HashMap<Vertex , Shape >(); 
private final HashMap<Edge , Shape> 
HashMap<Edge , Shape > () ; 
private MovementMap 

protected Double vertexRadius = 3.0d; 
protected Double edgeRadius = 2.0d; 



vertexShapeMap = new 

edgeShapeMap = new 

offset VertexShapeMap = new 
offsetEdgeShapeMap = ne 

vertexOffsetMap = null ; 



private Color backgroundColour = Color . white ; 

private BasicStroke edgeStroke = new BasicStroke ( 1 . f ) 

private BasicStroke vertexStroke = new BasicStroke ( 1 . f ) ; 
private boolean show VertexLabel = true ; 
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private Color edgeColour 

private Color vertexColour 

private Color vertexFillColour 

private Color textColour 

private Font labelFont 



= Color . black ; 
= Color . black ; 

= getBackgroundColour ( ) ; 
= Color . black ; 

= new Font( "Arial", Font. BOLD, 10 



private BasicStroke offsetEdgeStroke = new B asicS t roke ( 1 . f ) 

private BasicStroke offset VertexStroke = new BasicStroke ( 1 . f ) ; 



private Color offsetEdgeColour 

private Color of fset VertexColour 

private Color offset VertexFillColour 

private Color offsetTextColour 

private Font offsetLabelFont 



= Color . blue ; 
= Color . blue ; 

= getBackgroundColour ( ) 
= Color . blue ; 
= getFont ( ) ; 



83 
84 



87 
88 



95 
96 



101 
102 
103 
101 
105 
106 
107 

109 
110 



111 
115 
116 

118 
119 

120 
121 
122 

124 
125 
126 



protected Rectangle bounds; 

protected BasicStroke outlineStroke = new BasicStroke ( 1 . f ) ; 
protected Color outlineColour = Color .BLACK; 

public View ( VertexLayout layout) { 
super ( ) ; 

this . layout = layout ; 
view = null ; 
bounds = getBoundsQ ; 
s e t S e 1 f L is t e ne r s () ; 

if ( MTNIMUM_SIZE != null ) setMinimumSize (MINIMUM_SIZE) ; 

if ( PREFERRED_SIZE != null ) set Prefer r edSize (PREFERRED_SIZE) ; 
if ( MAXTMUM_SIZE != null ) setMaximumSize (MAXTMUM_SIZE) ; 

} 

public View(View view) { 
super ( ) ; 

layout = view . getGraphLayout ( ) ; 
this, view = view; 
bounds = getBoundsQ ; 
s e t S e 1 f L is t e ne r s () ; 

} 

private void s e t S e 1 f L i s t e n e r s ( ) { 
addMouseListener ( this ); 
addMouseMotionListener ( this ); 
addKey Listener ( this ); 
addComponentListener ( this ); 
layout . addGraphLayoutListener ( this ); 

} 

public VertexLayout getGraphLayout ( ) { return layout; } 

public View getPreviousView ( ) { return view; } 

protected abstract void ge ner at elni t ialD at a ( ) ; 

protected Shape get VertexShape ( final Vertex vertex ) { 
return vertexShapeMap . get ( vertex ) ; 

} 

protected void set VertexShape ( final Vertex vertex , final Shape shape ) { 
if ( vertexShapeMap . containsKey (vertex) ) 

vertexShapeMap . remove ( vertex ) ; 
vertexShapeMap. put (vertex , shape) ; 

} 

protected Shape getEdgeShape ( final Edge edge) { 
return edgeShapeMap . get ( edge ) ; 

} 

protected void setEdgeShape ( final Edge edge, final Shape shape ) { 
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129 if (edgeShapeMap . containsKey ( edge ) ) 

130 edgeShapeMap . remove ( edge ) ; 

131 if ( shape != null ) 

132 edgeShapeMap . put ( edge , shape); 

133 } 

135 protected Shape generate VertexShape ( final Vertex vertex) { 

136 if (vertex = null) 

137 return null ; 

138 final Point2D . Double p = invertComponentLocation ( 
getGraphLayout () . getVertexLocation(vertex) ) ; 

139 return new Ellipse2D . Double ( 

140 p.x — vertexRadius , 

141 p.y — vertexRadius , 

142 2 * vertexRadius , 2 * vertexRadius 

143 ) ; 

144 } 

146 protected Shape generateEdgeShape ( final Point2D . Double from, final 
Point2D . Double to ) { 

147 if (from = null | | to = null) 

148 return null ; 

149 Point2D . Double vl = invertComponentLocation ( from ); 

150 Point2D . Double v2 = invertComponentLocation ( to ); 

151 return new Line2D . Double ( vl.x, vl.y, v2 . x , v2 . y ); 

152 } 

154 protected Shape generateEdgeShape ( final Edge edge) { 

155 if (edge = null) 

156 return null ; 

157 Point2D . Double vl = getGraphLayout (). get Vert exLocat ion ( edge . getFrom ()) ; 

158 Point2D . Double v2 = getGraphLayout (). get VertexLocation ( edge . getTo ()) ; 

159 return generateEdgeShape ( vl , v2 ); 

160 } 

162 protected Shape getOffset VertexShape ( final Vertex vertex ) { 

163 return offset VertexShapeMap . get ( vertex ) ; 

164 } 

166 protected void set O ff set Vert exShape ( final Vertex vertex , final Shape shape ) 
{ 

167 if ( offsetVertexShapeMap . containsKey ( vertex ) ) 

168 offsetVertexShapeMap . remove ( vertex ) ; 

169 if ( shape != null ) 

170 offset VertexShapeMap . put ( vertex , shape); 

171 } 

173 protected Shape getOffsetEdgeShape ( final Edge edge ) { 

174 return offsetEdgeShapeMap . get ( edge ) ; 

175 } 

177 protected void setOffsetEdgeShape ( final Edge edge, final Shape shape ) { 

178 if ( offsetEdgeShapeMap . containsKey ( edge ) ) 

179 offsetEdgeShapeMap . remove ( edge ) ; 

180 if ( shape != null ) 

181 offsetEdgeShapeMap . put ( edge , shape); 

182 } 



184 
185 



protected Shape generateOffsetVertexShape ( final Vertex vertex ) { 
if ( vertex = null | | vertexOffsetMap = null | 
! vertexOffsetMap . contains (vertex) ) 

186 return null ; 

187 final Point2D . Double offset = vertexOffsetMap . get VertexOffset ( vertex ) 
if ( offset = null ) return null; 



188 
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190 
191 
192 
193 
194 
195 



} 



final Point2D . Double p = invertComponentLocation ( 
getGraphLayout (). get VertexLocation ( vertex , offset) ) 
return new Ellipse2D . Double ( 



p.x — vertexRadius , 
p.y — vertexRadius , 
2 * vertexRadius , 2 



* vertexRadius 



19* 
199 

200 
201 
2012 
203 

204 
205 
206 
207 
208 

209 
210 
211 
212 

214 
215 
216 
217 
218 
219 
220 
221 
222 
223 
224 
225 
22G 
227 
228 
229 
230 
231 
232 
233 
234 
235 

237 
238 
239 
240 
241 
212 
243 
244 
245 
246 
247 
248 



protected Shape generateOffsetEdgeShape ( final Edge edge) { 
if (edge = null | | vertexOffsetMap = null 

(! vertexOffsetMap . contains (edge . get From ( ) ) &fe 
! vertexOffsetMap . contains (edge . get To ( ) ) ) ) 
return null ; 
Point2D . Double vl ; 

if ( vertexOffsetMap . contains ( edge . getFrom () ) ) 

vl = getGraphLayout ( ) . get VertexLocation ( edge . getFrom ( ) , 
vertexOffsetMap . get VertexOffset ( edge . getFrom ( ) )); 

else 

vl = getGraphLayout (). get Vert exLocat ion ( edge . getFrom ()) ; 
Point2D . Double v2 ; 

if ( vert exOffset Map . cont ains ( edge . getTo ()) ) 

v2 = getGraphLayout (). get VertexLocation ( edge . getTo () , 
vertexOffsetMap . get VertexOffset ( edge. getTo () )); 

else 

v2 = getGraphLayout (). get VertexLocation ( edge . getTo ()) ; 
return generateEdgeShape ( vl , v2 ); 

} 

public void setOffsetMovementMap ( final MovementMap map ) { 
offsetEdgeShapeMap . clear () ; 
offset VertexShapeMap . clear () ; 
if ( map = null ) { 

vertexOffsetMap = null ; 

return ; 

} 

if ( map . getLayout ( ) != getGraphLayout () ) 
return ; 

this . vertexOffsetMap = map; 

final Graph graph = getGraphLayout ( ) .getGraphQ ; 
HashSet<Edge> edges = new HashSet<Edge > () ; 
for ( final Vertex vertex: map . get Vert ices () ) 
if ( graph . contains ( vertex ) ) { 

set O ff set Vert exShape ( vertex, generateOffsetVertexShape ( vertex ) ) 
for ( Edge edge: vertex . getConnectedEdges ( ) ) 
if ( ! edges . contains ( edge ) ) { 

setOffsetEdgeShape ( edge, generateOffsetEdgeShape ( edge ) ); 
edges . add ( edge ) ; 

} 



} 

public 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 



} 



Color getBackgroundColour () 
boolean isShowingVertexLabel ( ) 
BasicStroke getEdgeStroke ( ) 
BasicStroke get Vert exSt roke ( ) 
Color getEdgeColour ( ) 
Color get VertexColour ( ) 
Color get VertexFillColour ( ) 
Color getTextColour () 
Font getFontQ 

BasicStroke get O ut line St roke ( ) 
Color get Out lineColour ( ) 
Rectangle getBoundsQ 



{ return backgroundColour ; } 



{ return showVertexLabel ; 
{ return edgeStroke ; } 
{ return vertexStroke ; } 

{ return edgeColour ; } 

{ return vertexColour ; } 
{ return VertexFillColour : 

{ return textColour ; } 

{ return labelFont ; } 

{ return outlineStroke ; } 
{ return outlineColour ; } 

{ return bounds ; } 



} 
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250 
251 
252 
253 
254 
255 
256 



279 
280 
281 
282 
283 
284 

286 
287 
288 



292 
293 



public BasicStroke get Of f set EdgeS t r oke ( ) { return offsetEdgeStroke ; } 

public BasicStroke getOffset VertexStroke ( ) { return offset VertexStroke ; } 

public Color getOffsetEdgeColour ( ) { return offsetEdgeColour ; } 

public Color get Of f se t Vert exColour ( ) { return offset VertexColour ; } 

public Color get O ff set Vert exF ill C olour ( ) { return of f s et Ver t exF ill C o lo ur ; } 

public Color getOffsetTextColour ( ) { return of f set Text C o lour ; } 

public Font ge t O ff set Font ( ) { return offsetLabelFont ; } 



public void setShowVertexLabel (boolean show) 
show ; } 

public void setEdgeStroke ( BasicStroke stroke) 
stroke ; } 

public void set VertexStroke ( BasicStroke stroke) 
stroke ; } 

public void setEdgeColour ( Color colour) 
colour ; } 

public void set VertexColour ( Color colour) 
colour ; } 

public void set VertexFillColour ( Color colour) 
colour ; } 

public void setTextColour ( Color colour) 
colour ; } 

public void set O ut lineStr oke ( BasicStroke stroke) 
stroke ; } 

public void setOutlineColour ( Color colour) 
colour ; } 

public void setFont ( String name, int style , int size) 

name , style, size)); } 

public void setFont (Font font) 



{ showVertexLabel = 
{ edgeStroke = 
{ VertexStroke = 
{ edgeColour = 
{ VertexColour = 

{ VertexFillColour = 
{ textColour = 
{ outlineStroke = 
{ outlineColour = 
{ setFont ( new Font ( 
{ labelFont = font; } 
{ 

{ offset VertexStroke 
{ offsetEdgeColour = 
{ offset VertexColour 
{ 

{ offsetTextColour = 
{ offsetLabelFont = 



public void set O ff set EdgeS t r oke ( B asicSt roke stroke) 
offsetEdgeStroke = stroke ; } 

public void set O ff set Ver t exSt roke ( B asicSt roke stroke) 
= stroke ; } 

public void setOffsetEdgeColour ( Color colour) 
colour ; } 

public void setOffset VertexColour ( Color colour) 
= colour ; } 

public void se t O ff set Ver texFill C olour ( Color colour) 
offset VertexFillColour = colour ; } 
public void setOffsetTextColour ( Color colour) 
colour ; } 

public void se t O ffset Font ( Font font) 
font ; } 

public void setOffsetFont ( String name, int style , int size) { 
setOffsetFont (new Font ( name, style, size )); } 

protected Point2D . Double translateComponentLocation ( Point p ) { 
if ( p.x < bounds . getMinX ( ) || p.y < bounds . getMinY ( ) 

p.x > bounds . getMaxX ( ) || p.y > bounds . getMaxY () ) 
return null ; 

return translateComponentLocationlgnoreBounds ( p ); 

} 

protected Point2D . Double translateComponentLocationlgnoreBounds ( Point p ) { 
double x = ( p.x — bounds . x ) * 100. Od / (double) bounds . width ; 
double y = ( p.y — bounds . y ) * 100. Od / (double) bounds . height ; 
return new Point2D . Double ( x, y ); 

} 

protected Point2D . Double invertComponentLocation ( Point2D . Double p ) { 

return new Point2D . Double ( bounds . width * p.x / 100, bounds . height * p.y / 
100 ); 

} 
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296 protected boolean cont ains ( Point2D . Double p, Vertex vertex) { 

297 if (vertex != null) { 

298 Point2D . Double v = getGraphLayout (). get VertexLocation ( vertex ) 

299 double dx = v.x — p.x; 

300 double dy = v . y — p . y ; 

301 return dx * dx + dy * dy <= vertexRadius * vertexRadius ; 

302 } 

303 return false ; 

304 } 



306 
307 
308 
309 
310 
311 

312 
313 
314 
315 
316 
317 
318 
319 
320 
321 
322 
323 
324 
325 
326 
327 
328 
329 
330 
331 
332 
333 
334 



353 
354 



protected boolean contains ( Point2D . Double p, Edge edge) { 
if ( edge != null ) { 

Point2D . Double f = getGraphLayout (). get VertexLocation ( edge . getFrom ( ) ) 
Point2D . Double t = getGraphLayout (). get VertexLocation ( edge.getToQ ); 
if ( f.x=t.x&&f.y=t.y ) { 

return ( (p.x — f.x) * (p.x — f.x) + (p.y — f.y) * (p.y — f.y) <= 
edgeRadius * edgeRadius ) ; 
} else { 



double tx = t 

double ty = t 

double px = p.x 

double py = p.y 



y 



s i n 
s i n 



py. 

px; 



- f.x; 

- f.y; 

- f.x; 

- f-y; 

double d = Math.sqrt( tx * tx 
double sin = ty / d; 
double cos = tx / d; 
double x = cos * px 
double y = cos * py 
if ( Math . abs ( y ) > edgeRadius 

return false ; 
if ( x < ) { 

return ( x * x + y 
} else if ( x > d ) { 

return ( (x — d) * (x 
} else { 

return true ; 

} 



ty 



ty ) 



) 

y <= edgeRadius * edgeRadius ) ; 

d) + y * y <= edgeRadius * edgeRadius ) ; 



} 

return false 



} 



336 protected Vertex get VertexContaining ( Point p) { 

337 Point2D . Double p2d = translateComponentLocation ( p ); 

338 for (Vertex vertex: getGraphLayout (). get Graph (). get Vert ice s () ) 

339 if ( contains ( p2d , vertex )) 

340 return vertex ; 

341 return null ; 

342 } 

344 protected Edge getEdgeContaining ( Point p) { 

345 Point2D . Double p2d = translateComponentLocation ( p ); 

346 for (Edge edge: getGraphLayout (). getGraph (). getEdges () ) 

347 if ( contains ( p2d , edge )) 

348 return edge ; 

349 return null ; 

350 } 

protected boolean isBetween ( final Vertex vertex, final Point2D . Double pi, 
final Point2D . Double p2) { 

Point2D . Double v = getGraphLayout (). get VertexLocation ( vertex ); 
return ( pl.x <= v.x ) && ( v.x <= p2.x ) && ( pl.y <= v.y ) && ( v.y < 
P2.y ) ; 

} 
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protected boolean isBetween ( final Edge edge, final Point2D . Double pi, final 
Point2D . Double p2) { 

return isBetween ( edge . getFrom ( ) , pi , p2 ) &fe isBetween( edge.getToQ , pi. 
p2 ) ; 

} 

protected HashSet<Vertex> get VerticesWithin ( final Rectangle r) { 

362 if ( r = null ) 

363 return null ; 

364 final HashSet<Vertex> matchedVertices = new HashSet<Vertex > () ; 

365 Point2D . Double pi = translateComponentLocationlgnoreBounds ( new Point ( 
(int) r.getMinXQ, (int) r.getMinYQ ) ); 

Point2D . Double p2 = translateComponentLocationlgnoreBounds ( new Point ( 
(int) r . getMaxX ( ) , (int) r.getMaxYQ ) ); 

367 for (Vertex vertex: getGraphLayout (). get Graph (). get Vert ice s () ) 

368 if ( isBetween ( vertex , pi , p2 ) ) 

369 matched Vertices . add ( vertex ); 

370 return matchedVertices ; 



371 



} 



373 protected HashSet<Edge> getEdgesWithin ( final Rectangle r) { 

374 if ( r = null ) 

375 return null ; 

376 final HashSet<Edge> matchedVertices = new HashSet <Edge > () ; 

377 Point2D . Double pi = translateComponentLocationlgnoreBounds ( new Point ( 
(int) r.getMinXQ, (int) r.getMinYQ ) ); 

Point2D . Double p2 = translateComponentLocationlgnoreBounds ( new Point ( 
(int) r . getMaxX ( ) , (int) r.getMaxYQ ) ); 

379 for (Edge edge: get GraphLayout (). getGraph (). get Edges () ) 

380 if ( isBetween ( edge, pi , p2 ) ) 

381 matched Vertices . add ( edge ); 

382 return matchedVertices ; 

383 } 

386 protected void paintBorder( Graphics2D g2d ) { 

387 int border = (int) Math, ceil ( o u t lineS t r oke . getLineWidt h ( ) / 2 ); 

388 g2d . set S t roke ( outlineStroke ); 

389 g2d . setColor ( outlineColour ); 

390 g2d . drawRect ( —border, —border, bounds . width + border, bounds . height + 
border ) ; 

} 

393 protected void paint S et Vert exStyle ( Vertex vertex , Graphics2D g2d ) { 

394 g2d . setStroke ( getEdgeStroke () ) ; 

395 g2d . setColor ( getVertexColour () ) ; 

396 } 

398 protected void p ai n t S et Ver t exF i US t y le ( Vertex vertex , Graphics2D g2d ) { 

399 g2d . setStroke ( getEdgeStroke () ) ; 

400 g2d.setColor(getVertexFillColourQ); 

401 } 

403 protected void p ain t S e t Of f set Vert exS t y le ( Vertex vertex , Graphics2D g2d ) { 

404 g2d . setStroke ( getOffsetEdgeStroke () ) ; 

405 g2d . setColor ( getOffsetVertexColour () ) ; 

406 } 

protected void p aint S et O f f s et Ver t ex F i 11 S t y 1 e ( Vertex vertex, Graphics2D g2d ) 
{ 

409 g2d . setStroke (getOffsetEdgeStroke () ) ; 

410 g2d . setColor ( get Off set VertexFillColour ()) ; 

411 } 

protected void paintSetEdgeStyle ( Edge edge, Graphics2D g2d ) { 
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414 g2d.setStroke(getEdgeStroke()) 

415 g2d.setColor(getEdgeColour()); 
} 



116 



418 protected void paint Set O ffset Edge St yle ( Edge edge, Graphics2D g2d ) { 

419 g2d . setStroke (ge tO ffset Edge Stroke ()); 

420 g2d . setColor ( getOffsetEdgeColour () ) ; 

421 } 



423 protected void paintVertex( Vertex vertex , Graphics2D g2d ) { 

424 Shape shape = get VertexShape ( vertex ); 

425 pai nt S et Vert exF i 1 1 S t yle ( vertex, g2d ); 

426 g2d . fill (shape) ; 

427 paint S et Vert exSt yle ( vertex, g2d ); 

428 g2d . draw ( shape ) ; 

429 } 

431 protected void paint Offset Vertex ( Vertex vertex , Graphics2D g2d ) { 

432 Shape shape = getOffset VertexShape ( vertex ); 

433 pain t S e 1 f f s e t Ve r t exF i 11 S t y le ( vertex, g2d ); 

434 g2d. fill (shape) ; 

435 p ai nt S et O ffset Vert exSt yle ( vertex, g2d ); 

436 g2d . draw ( shape ) ; 

437 } 

439 protected void paint VertexLabel ( Vertex vertex , Graphics2D g2d ) { 

440 Shape shape = get VertexShape ( vertex ); 

441 i f (! vert ex . t oS t ring (). equals ("" ) && isShowingVertexLabel ( ) ) { 

442 g2d. setColor(getTextColour() ) ; 

443 Font font = getFontQ ; 

444 Rectangle bounds = shape . getBounds ( ) ; 

445 int x = bounds . x + bounds . width + 2; 

446 int y = bounds . y + bounds . height + 2; 

448 FontRenderContext frc = g2d . getFontRenderContext ( ) ; 

449 TextLayout labelLayout = new TextLayout ( vert ex . t o S t r ing ( ) , font , frc) 

450 labelLayout . draw ( g2d , x, y) ; 

451 } 

•■->■> } 

454 protected void paintEdge( Edge edge, Graphics2D g2d ) { 

455 paintSetEdgeStyle ( edge, g2d ); 

456 g2d . draw ( get Edge Shape ( edge ) ) ; 

457 } 

459 protected void paintOffsetEdge ( Edge edge, Graphics2D g2d ) { 

460 paint Set O ffset Edge St yle ( edge, g2d ); 

461 g2d . draw (getOffsetEdgeShape(edge)) ; 



462 } 



16 1 



protected void beforePaint ( final Graphics2D g2d ) { 

465 g2d . setColor ( getBackgroundColour ( ) ); 

466 g2d . f illRect ( 0, 0, getWidthQ, getHeight ( ) ) ; 

467 g2d . t r an s 1 at e ( bounds. x, bounds. y); 

468 if (outlineStroke != null) 

469 paintBorder( g2d ); 

470 g2d . se t C lip ( , 0, bounds . width , bounds . height ) ; 

471 } 



protected void afterPaint ( final Graphics2D g2d ) { 

474 g2d . t r an s 1 at e ( — bounds. x, — bounds. y); 

475 } 

protected void paint ( final Graphics g, final boolean paintBackground ) { 

477 if ( bounds = null ) 

478 return ; 



473 
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479 Graphics2D g2d = (Graphics2D) g; 

4so if ( paintBackground ) { 

4si beforePaint ( g2d ) ; 

482 } 

483 Array List <Edge> edges = getGraphLayout ( ) .getGraphQ .getEdgesQ ; 

484 Array List <Vertex> vertices = get GraphLayout (). getGraph (). get Vert ices () ; 

485 for (Edge edge: edges) { 

486 paintEdge( edge , g2d ) ; 

487 if ( vertexOffsetMap != null && 

488 ( vert exOffset Map . cont ains ( edge . getTo () ) 
vertexOffsetMap. contains (edge, get From ( ) ) ) ) { 

489 paintOffsetEdge ( edge, g2d ); 

490 } 

491 } 

492 for (Vertex vertex: vertices) { 

493 paint Vertex ( vertex, g2d ); 

494 paint VertexLabel ( vertex , g2d ) ; 

495 if ( vertexOffsetMap != null && vertexOffsetMap . contains ( vertex ) ) 

496 paint O ff set Vert ex ( vertex , g2d ) ; 

497 } 

498 if ( paintBackground ) { 
afterPaint ( g2d ) ; 

500 } 

501 } 

502 public void paint ( Graphics g) { 

503 paint ( g, true ); 

504 } 

506 protected void regenerateView ( MovementMap map ) { 

507 for (Vertex vertex: getGraphLayout (). get Graph (). get Vert ice s () ) 

508 if ( map = null || map . cont ains ( vert ex ) ) { 

509 set VertexShape ( vertex, generateVertexShape ( vertex ) ); 

510 set O ff set Vert exShape ( vertex, generateOffsetVertexShape ( vertex ) ) 

511 } 

512 for ( Edge edge: getGraphLayout (). getGraph (). getEdges ( ) ) 

513 if ( map = null || map . con t ains ( edge . getFrom ( ) ) || map . contains ( 
edge. getTo () ) ) { 

514 setEdgeShape ( edge, generateEdgeShape ( edge ) ); 

515 setOffsetEdgeShape ( edge, generateOffsetEdgeShape ( edge ) ); 

516 } 

517 } 



519 



public void regenerateBounds ( ) { 

520 Dimension d = getSize () ; 

521 int border = (int) Math, ceil ( outlineStroke . getLineWidth ( ) ); 

522 bounds = new Rectangle ( border, border, d. width — 2 * border, d. height 
* border ) ; 

523 if (d. width > d. height) 

524 bounds = new Rectangle ( 

525 (d. width — d. height) / 2 + border, 

526 border , 

527 d. height — 2 * border , 

528 d. height — 2 * border 

529 ) ; 

530 else 

531 bounds = new Rectangle ( 

532 border , 

533 (d. height — d. width) / 2 + border, 

534 d. width — 2 * border , 

535 d. width — 2 * border 

536 ) ; 

537 // System . err . println ( " View . regenerateBounds () : (" + d. width + ", " + 
d. height + " ), (" + bounds. x + ", " + bounds . y + ", " + bounds . width + ", " 
bounds . height + "]" ); 

regenerateView ( null ); 
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539 
540 

5 12 
543 
544 
545 
546 

548 
549 
550 
551 

553 
554 
555 
556 
557 
558 
559 



} 



repaint ( ) ; 



©Override 

public void handleGraphLayoutChanged ( GraphLayoutEvent event) { 
regenerateView ( event . getMovementMap ( ) ); 
repaint () ; 

} 

©Override 

public void componentResized ( ComponentEvent event) { 
regenerateBounds ( ) ; 

} 



// 



©Override 
public void 
switch ( 
case 26 
case 2 5 
default 
System 



keyTyped ( KeyEvent event) 
event . getKeyChar ( ) ) { 
getGraphLayout ( ) ,undo() ; 
getGraphLayout () . redo () ; 



break ; / / 

// Ctrl-y 



Ctrl- 



560 


} 






561 


} 






563 


©Override 


public 


void 


564 


©Override 


public 


void 


565 


©Override 


public 


void 


566 


©Override 


public 


void 


567 


©Override 


public 


void 


568 


©Override 


public 


void 


569 


©Override 


public 


void 


570 


©Override 


public 


void 


571 


©Override 


public 


void 


572 


©Override 


public 


void 


573 


©Override 


public 


void 


574 


©Override 


public 


void 


575 


} 







println( (int) event . getKeyChar ( ) ); 



componentHidden ( ComponentEvent event) {} 
componentMoved ( ComponentEvent event) {} 
componentShown ( ComponentEvent event) {} 
mouseClicked ( MouseEvent argO) {} 
mouseEntered ( MouseEvent argO) {} 
mouseExited ( MouseEvent argO) {} 
mousePressed ( MouseEvent argO) {} 
mouseReleased ( MouseEvent argO) {} 
mouseDragged ( MouseEvent argO ) {} 
mouseMoved ( MouseEvent argO) {} 
key Pressed ( KeyEvent argO) {} 
key Released ( KeyEvent argO) {} 



D.5.8 mgtaylor. display. data.BlockDataView 



package mgtaylor . display . data ; 

import java . awt . * ; 

mport javax . swing . * ; 
mport javax . swing . table . * ; 

mport mgtaylor . display . PlanarityHandler ; 
mport mgtaylor . display . data . event . * ; 

mport mgtaylor . datastructures . UnmodifiableLinkList ; 
mport mgtaylor . graph . Block ; 
mport mgtaylor . graph . Segment ; 
mport mgtaylor . layout . * ; 

mport mgtaylor . layout . event . GraphLayoutEvent ; 
import mgtaylor . planarity . event . * ; 

public class BlockDataView extends DataView { 

/ * * * / 

private static final long serialVersionUID = -6835917939703146492L ; 
private final BlockTableModel model; 
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// private final JComponentTableRenderer Tenderer = new 
JComponentTableRenderer ( ) ; 

public BlockDataView ( final VertexLayout layout , final Planarity Handler 

planarity ) { 

super ( layout ) ; 

final UnmodifiableLinkList <Block> blocks = 
layout . get Graph () . getAHBlocks () ; 

final Block[] data = new Block [ blocks . size () ] ; 
int i = 0; 

for ( Block block : blocks ) { 
data[ i++ ] = block; 

} 

model = new BlockTableModel ( data ) ; 
JTable table = new JTable( model ) ; 
JScrollPane scroll = new JScrollPane( table ); 
table . setFills ViewportHeight ( true ) ; 

if ( table . getColumnCount () > ) { 

JTableButtonListener flipListener = new JTableButtonListener ( ) { 
public void tableButtonPressed ( JTableButtonEvent event) { 

Block block = (Block) model . get ValueAt ( event . getRow () , 0); 
if ( block . isFlippable () ) { 
block . invert ( ) ; 
model . fireTableDataChanged () ; 
layout . get Graph () .generateEdgeSidesQ ; 

planarity . processPlanarOrderEvent ( new PlanarOrderEvent ( 
planarity ) ) ; 

} 

} 

}; 

ButtonColumn flipColumn = new ButtonColumn ( table , 1 ) ; 
flipColumn . addTableButtonListener ( flipListener ); 

} 

setLayout( new BorderLayout ( ) ); 
add( scroll, BorderLayout .CENTER. ) ; 



©Override 

public void handleGraphLayoutChanged ( final GraphLayoutEvent event) {} 

public static class BlockTableModel extends AbstractTableModel { 

private static final long serialVersionUID = -8006 17633 1 578385316L ; 
final Class <?>[] types = new Class <?>[] { 

Block . class , 

String . class , 

Boolean . class , 

Boolean . class , 

Segment . class , 

String . class 

}; 

final String [] headers = new String [] { 
"Block " , 
"Flip" , 
" Can Flip? " , 
" Is Flipped? " , 
" Parent " , 
" Status " 

}; 
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private final Block [] data; 

87 public BlockTableModel ( Block [] data ) { 

88 this . data = data; 
} 

public String getColumnName ( int col) { return headers [ col ] ; } 



95 
9(3 



100 
101 
102 
103 
101 
105 
106 
107 
108 
109 
110 



public int getRowCount ( ) { return data, length; } 
public int getColumnCount ( ) { 

if ( data != null && data, length > ) 
return headers . length ; 



return 


0; 


} 




public Object get ValueAt ( int 


switch( col ) { 


case 


return data [row]; 


case 1 


return " > " ; 


case 2 


return data [row]. 


case 3 


return data [row]. 


case 4 


return data [row]. 


case 5 


return (data [row] 



} 

return null : 



} 



112 
113 
114 



public Class<?> getColumnClass ( int c) { 
return types [c ] ; 

} 



116 
117 
118 
119 
120 
121 



public boolean isCellEditable ( int row, int col) { 
return col = 1; 

} 

public void set ValueAt ( Object value, int row, int col) {} 



D.5.9 mgtaylor.display.data.ButtonColumn 



package mgtaylor . display . data ; 



mport 
mport 
mport 
mport 

mport 
mport 
mport 
mport 
mport 
mport 
import j 



ava . awt . Component ; 
ava . awt . event . ActionEvent ; 
ava . awt . event . ActionListener : 
ava . u t i 1 . * ; 



avax 
avax 
avax 
avax 
avax 
avax 
avax 



swing 
swing 
swing 
swing 
swing 
swing 
swing 



AbstractCellEditor ; 
JButton ; 
JTable ; 
UIManager ; 

table . TableCellEditor ; 
table . TableCellRenderer : 
table . TableColumnModel ; 



import mgtaylor . display . data . event . * ; 



public class ButtonColumn extends AbstractCellEditor 
implements TableCellRenderer , TableCellEditor , ActionListener 
JTableButtonHandler { 
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/* * 
* 

*/ 

private static final long serial VersionUID = 2985480381256465894L ; 

private final HashSet<JTableButtonListener> listeners = new 

HashSet<JTableButtonListener >() ; 

private final JTable table ; 

private final JButton renderButton ; 

private final JButton editButton; 

private String text = null; 

public ButtonColumn ( JTable table , int column) 
{ 

super ( ) ; 

this . table = table ; 
renderButton = new JButton () ; 

editButton = new JButtonQ ; 
editButton . setFocusPainted ( false ); 
editButton . add ActionListener ( this ); 

TableColumnModel columnModel = t able . getColumnModel ( ) ; 
columnModel . getColumn ( column ). set C ellRenderer ( this ); 
columnModel . getColumn ( column ). set C e 1 1 E d it or ( this ); 

} 

public Component getTableCellRendererComponent ( 

JTable table , Object value , boolean isSelected , boolean hasFocus , int 
row, int column) 

{ 

if (hasFocus | | ! isSelected ) { 

renderButton . setForeground ( table . getForeground () ) ; 

renderButton . setBackground( UIManager . getColor(" Button, background " ) ) ; 
} else { 

renderButton . setForeground ( table . getForeground () ) ; 
renderButton . setBackground ( table . getSelectionBackground () ) ; 

} 

renderButton . setText ( (value = null) ? "" : value . toString ( ) ); 
return renderButton ; 

} 

public Component getTableCellEditorComponent ( 

JTable table , Object value , boolean isSelected , int row, int column) 

{ 

text = (value = null) ? "" : value . to St ring () ; 
editButton . setText ( text ) ; 
return editButton ; 

} 

public Object get C ellEdit or Value ( ) 
{ 

return text ; 

} 

public void actionPerformed ( ActionEvent e) { 
fireEditingStopped () ; 

// System . out . println ( e . getActionCommand ( ) + " : " + table . get SelectedRow ()) ; 
fireTableButtonPressed ( new JTableButtonEvent ( e, table ) ); 

} 

©Override 

public void addTableButtonListener ( JTableButtonListener listener) { 
listeners . add (listener); 

} 
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©Override 

public void fireTableButtonPressed ( JTableButtonEvent event) { 

87 for ( JTableButtonListener listener: listeners ) 

88 1 i s t e n e r . t ableB utt onP ressed ( event ); 

} 

©Override 

public void removeTableButtonListener ( JTableButtonListener listener) { 
listeners . remove (listener); 

} 

} 



D.5.10 mgtaylor. display. data.DataView 

package mgtaylor . display . data ; 

import javax . swing . * ; 

import mgtaylor . layout . * ; 
import mgtaylor . layout . event . * ; 



public abstract class DataView extends JPanel implements GraphLayoutListener { 

/ * * */ 

private static final long serialVersionUID = -4078807160909725515L ; 

protected final VertexLayout layout ; 

public DataView( final VertexLayout layout ) { 
this . layout = layout ; 

layout . addGraphLayoutListener ( this ); 

} 

protected VertexLayout getGraphLayout ( ) { 
return layout ; 

} 

public abstract void handleGrapliLayoutChanged ( final GraphLayoutEvent event 



D.5.11 mgtaylor. display, data. PermutationDataView 



package mgtaylor . display . data ; 



import java.awt. 



mport javax . swing . * ; 

mport j avax . swing . t able .* ; 

mport mgtaylor . display . PlanarityHandler ; 

mport mgtaylor . display . data . event . * ; 

mport mgtaylor . layout . * ; 

mport mgtaylor . layout . event . * ; 

mport mgtaylor . planarity . event . PlanarOrderEvent ; 

mport mgtaylor . graph . Segment ; 

mport mgtaylor . graph . SegmentPermutation ; 

import mgtaylor . datastructures . UnmodifiableLinkList ; 
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public class PermutationDataView extends DataView { 

/* * * / 

private static final long serial VersionUID = -6835917939703146492L ; 

private final PermutationTableModel model; 

// private final JComponentTableRenderer Tenderer = new 
JComponentTableRenderer () ; 

public PermutationDataView ( final VertexLayout layout , final Planarity Handler 

planarity ) { 

super ( layout ) ; 

final UnmodifiableLinkList <SegmentPermutation> permutations = 
layout . getGraph () . getPermutations () ; 

final SegmentPermutation [] data = new 
Segment Per mutation [permutations . size () ] ; 
int i = 0; 

for ( SegmentPermutation permutation : permutations ) { 
data[ i ] = permutation; 

} 

model = new PermutationTableModel ( data ); 
JTable table = new JTable( model ) ; 
JScrollPane scroll = new JScrollPane( table ); 
table . setFills ViewportHeight ( true ) ; 

if ( table . getColumnCount () > ) { 

JTableButtonListener r ese t L i s t ene r = new JTableB utt onList ener ( ) { 
public void tableButtonPressed ( JTableButtonEvent event) { 

SegmentPermutation permutation = (SegmentPermutation) data [ 
event . getRow ( ) ]; 

permutation . jumpToPermutation ( ); 

model . fireTableDataChanged () ; 

layout . getGraph () .generateEdgeSidesQ ; 

planarity . processPlanarOrderEvent ( new PlanarOrderEvent ( 
planarity ) ) ; 

} 

}; 

JTableButtonListener nextListener = new JTableButtonListener ( ) { 
public void tableButtonPressed ( JTableButtonEvent event) { 

SegmentPermutation permutation = (SegmentPermutation) data [ 

event . getRow ( ) ]; 

permutation. nextPermut at ion () ; 

model . fireTableDataChanged () ; 

layout . getGraph () .generateEdgeSidesQ ; 

planarity . processPlanarOrderEvent ( new PlanarOrderEvent ( 
planarity ) ) ; 

} 

}; 

ButtonColumn resetColumn = new ButtonColumn ( table , ) ; 
resetColumn . addTableButtonListener ( r e s e t L is t e ne r ); 

ButtonColumn nextColumn = new ButtonColumn ( table , 2 ) ; 
nextColumn . addTableButtonListener ( nextListener ); 

} 

setLayout( new BorderLayout ( ) ); 
add( scroll , BorderLayout .CENTER ); 

} 
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©Override 

public void handleGraphLayoutChanged ( final GraphLayoutEvent event) {} 
public static class PermutationTableModel extends AbstractTableModel { 

/ 5f: * / 

private static final long serialVersionUID = - 8006 17633 1 578385316L ; 
final Class <?>[] types = new Class <?>[] { 
si String . class , 

82 SegmentPermutation . class , 

String . class , 
Boolean . class , 
ss Segment . class , 

se Segment . class , 

Integer . class , 
Integer . class 

89 } ; 

90 final String [] headers = new String [] { 
Reset " , 
Permut at ion" , 

93 " Next " , 

94 "Is Permutable With Parent?", 
Parent " , 
First Child " , 

97 " Index " , 

98 "Total Permutations" 

}; 

private final SegmentPermutation]] data; 

103 public PermutationTableModel ( SegmentPermutation [] data ) { 

104 this . data = data; 

105 } 

public String getColumnName ( int col) { return headers [ col ] ; } 

109 public int getRowCount ( ) { return data, length; } 

no public int getColumnCount ( ) { 

in if ( data != null && data, length > ) 

112 return headers . length ; 

113 return 0; 

114 } 

116 public Object get ValueAt ( int row, int col) { 

117 switch( col ) { 
return " Reset " ; 

return data [row] . getPermutation () ; 
return " > " ; 

return data [row] . isPermutableWithParent () ; 
return data [row] . getParentSegment () ; 
return null; // data [ row ]. get First Child () ; 
return data [row] . getCurrentPermutation () ; 
return data [row] . getTotalPermutations () ; 



118 case 

119 case 1 

120 case 2 

121 case 3 

122 case 4 

123 case 5 

124 case 6 

125 case 7 

126 } 

127 return null ; 

128 } 

130 public Class<?> getColumnClass ( int c) { 

131 return types [c]; 

132 } 



134 public boolean isCellEditable ( int row, int col) { 

135 return col = | | col = 2; 
} 

public void set ValueAt ( Object value, int row, int col) {} 



136 
137 
138 
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D.5.12 mgtaylor. display, data. SegmentDataView 

package mgtaylor . display . data ; 

mport java . awt . * ; 
mport j ava . u t i 1 . * ; 

mport javax . swing . * ; 
mport j avax . swing . t able .* ; 

mport mgtaylor . layout . * ; 

mport mgtaylor . layout . event . * ; 

mport mgtaylor . planarity . event . PlanarOrderEvent ; 

mport mgtaylor . planarity . event . PlanarOrderListener ; 

mport mgtaylor . graph . Segment ; 
mport mgtaylor . graph . Block ; 

mport mgtaylor . datastructures . UnmodifiableLinkList ; 
import mgtaylor . display . PlanarityHandler ; 

public class SegmentDataView extends DataView implements PlanarOrderListener { 
private static final long serial VersionUID = -6835917939703146492L ; 
private final SegmentTableModel model; 

public SegmentDataView ( final VertexLayout layout , final PlanarityHandler 
planarity ) { 

super ( layout ) ; 

final UnmodifiableLinkList <Segment> segments = 
layout . get Graph () .getSegments() ; 

final Segment]] data = new Segment [ segments . s i z e ()] ; 
int i = 0; 

for ( Segment segment : segments ) { 

31 data] i++ ] = segment; 

32 } 

model = new SegmentTableModel ( data ) ; 
JTable table = new JTable( model ) ; 

35 JScrollPane scroll = new JScrollPane( table ); 

36 table . setFills ViewportHeight ( true ) ; 
setLayout( new BorderLayout ( ) ); 
add( scroll , BorderLayout .CENTER ); 

39 planarity . addPlanarOrderListener ( this ); 

40 } 

©Override 

public void handleGraphLayoutChanged ( final GraphLayoutEvent event) {} 
©Override 

public void handlePlanarOrderChanged ( PlanarOrderEvent event) { 
model . fireTableDataChanged () ; 

} 

private class SegmentTableModel extends AbstractTableModel { 

52 /***/ 

53 private static final long serialVersionUID = — 8006176331578385316L ; 
final Class <?>[] types = new Class <?>[] { 

Integer . class , 
String . class , 
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LinkedList . class , 
String . class , 
Boolean . class , 

60 Block . class , 

61 Boolean . class , 
Boolean . class , 
Boolean . class , 

64 String . class , 

65 String . class 

}; 

final String [] headers = new String [] { 

68 " ID" , 

69 " ROOt 11 , 

"Stem" , 
" Leaf " , 
" Can Flip? " , 
" Block " , 
"Block Flips?" , 
"Embedded" , 
"Clockwise " , 
"Side " , 
" Conflicts " 

}; 

private final Segment]] data; 

public SegmentTableModel ( Segment]] data ) { 
this . data = data ; 

} 

public String getColumnName ( int col) { return headers [ col ] ; } 

88 public int getRowCount ( ) { return data, length; } 

so public int getColumnCount ( ) { 

if ( data != null && data, length > ) 
return headers . length ; 

92 return 0; 

93 } 

public Object get ValueAt ( int row, int col) { 
Segment segment = data [row]; 

97 switch( col ) { 

98 case 0: return segment . getSegmentlndex ( ) ; 
case 1: return segment . get Root Vertex (). to S t ring ( ) + " (" + 
segment . getRootVertexDFSIndex ( ) + ")"; 

100 case 2: return segment . getStemVertices ( ) ; 

101 case 3: return segment . get LeafVert ex (). toS t ring ( ) + " (" + 
segment . getLeafVertexDFSIndex ( ) + ")"; 

102 case 4: return segment . i sF 1 i p p ab le () ; 
return segment . getEmbeddedBlock () ; 

return ( segment . getEmbeddedBlock ( ) = null ? null : new 
Boolean ( segment . getEmbeddedBlock () . isFlippableQ)) ; 
105 case 7: return segment . isEmbedded ( ) ; 

loe case 8: return new Boolean( segment . getEmbeddingDirection ( ) = 

Segment .CLOCKWISE ); 
107 case 9: return segment . get S ide ( ) = Block . INSIDE? " In ":" Out " ; 

los case 10: 

109 final StringBuffer out = new S t r ingB uf f er ( ) ; 

no out . append ( '<' ); 

in boolean first = true; 

112 for ( final Segment s: segment . get Conflict ingSegments ( ) ) { 

113 if ( first ) first = false; 

114 else out. append ( ", " ); 

115 out.append( s . getSegmentlndex ( ) ); 

116 } 

117 out . append ( '>' ); 



103 case 5 

104 case 6 
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123 
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130 



return out . t o S t ring ( ) 

} 

return null ; 



} 



public Class<?> getColumnClass ( int c) { 
return types [c ] ; 

} 

public boolean isCellEditable ( int row, int col) { return false; } 
public void set ValueAt ( Object value, int row, int col) {} 



D.5.13 mgtaylor. display, data. VertexDataView 



package mgtaylor . display . data ; 

mport java . awt . BorderLayout ; 

mport java. util .*; 

mport javax . swing . * ; 

mport javax . swing . table . AbstractTableModel ; 

mport mgtaylor . layout . * ; 

mport mgtaylor . layout . event . * ; 

mport mgtaylor . planarity . event . * ; 

mport mgtaylor . datastructures . UnmodifiableLinkList ; 

mport mgtaylor . display . PlanarityHandler ; 

import mgtaylor . graph . * ; 

public class VertexDataView extends DataView implements PlanarOrderListener { 

private static final long serial VersionUID = -6835917939703146492L ; 
private final Vertex [] data; 
private final VertexTableModel model; 

public VertexDataView ( final VertexLayout layout , final PlanarityHandler 
planarity ) { 

super ( layout ) ; 

final Graph graph = layout . getGraph () ; 

final Collection <Vertex> vertices = graph . get Vert ice s () ; 
data = new Vertex [ vertices . size () ] ; 
int i = 0; 

28 for ( Vertex vertex: vertices ) { 

29 data[ i ] = vertex; 

} 

32 model = new VertexTableModel ( data ) ; 

33 JTable table = new JTable( model ) ; 
JScrollPane scroll = new JScrollPane( table ); 
table . setFills ViewportHeight ( true ) ; 

36 setLayout( new BorderLayout ( ) ); 

37 add( scroll, BorderLayout .CENTER ) ; 
planarity . addPlanarOrderListener ( this ); 



©Override 

public void handleGraphLayoutChanged ( final GraphLayoutEvent event) {} 
©Override 

public void handlePlanarOrderChanged ( PlanarOrderEvent event) { 
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model . fireTableDataChanged () ; 

} 

private class VertexTableModel extends AbstractTableModel { 

private static final long serialVersionUID = - 8006 17633 1 578385316L ; 
final Class <?>[] types = new Class <?>[] { 

Vertex . class , 

ArrayList . class , 

Integer . class , 

Integer . class , 

Integer . class , 

ArrayList . class , 

Vertex . class , 

Segment . class , 

ArrayList . class 

}; 

private final String [] headers = new String [] { 
" Vertex " , 

"Adjacent Vertices", 

"DFS Index " , 

"Low Pt 1" , 

"Low Pt 2" , 

"DFS Adjacency" , 

" Parent " , 

" Segment " , 

"Planar Order" 

}; 



private final Vertex]] data; 



public VertexTableModel ( Vertex]] data ) { 
this. data = data; 

} 

public String getColumnName ( int col) { return headers [ col ] ; } 

public int getRowCount ( ) { return data, length; } 
public int getColumnCount ( ) { 

if ( data != null && data, length > ) 
return headers . length ; 

return 0; 

} 



public Object get ValueAt ( int row, int col) { 
switch( col ) { 
case 0: return data [row]; 

case 1: Array List <Edge> edges = data [ row ]. getConnectedEdges () ; 

ArrayList <Vertex> vertices = new ArrayList <Vertex >( edges, size () 

); 

for ( Edge edge : edges ) 

ver t ic es . add ( edge . getOtherEndFrom ( data[row] ) ); 

return vertices; 
case 2: return data [ row ]. getDFSIndex () ; 
case 3: return data [ row ]. getLowPoint 1 () ; 
case 4: return data [ row ]. getLowPoint2 () ; 
case 5: UnmodifiableLinkList <Edge> adjEdges = 
dat a [ row ] . getDFS Adj acency ( ) ;; 

ArrayList <Vertex> adjVertices = new ArrayList <Vertex >( 

adjEdges . size () ) ; 

for ( Edge edge: adjEdges ) 

ad j Ver t ices . add ( edge . getOtherEndFrom ( data[row] ) ); 

return adjVertices; 
case 6: return data [ row ]. getDFSParent () ; 
case 7: return data [ row ]. getSegment () ; 
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108 case 8: Edge[] ordEdges = data [ row ]. getEdgeOrder () ; 

109 ArrayList <Vertex> ordVertices = new ArrayList <Vertex >( 
ordEdges. length ) ; 

no for ( Edge edge : ordEdges ) 

in ordVertices . add ( edge . getOtherEndFrom ( data[row] ) ); 

112 return ordVertices ; 

113 } 

114 return null ; 

115 } 

117 public Class<?> getColumnClass ( int c) { 
us return types [c]; 

119 } 

121 public boolean isCellEditable ( int row, int col) { 

122 return false ; 

123 } 

124 public void set ValueAt ( Object value, int row, int col) {} 

125 } 

126 \ 



D.5.14 mgtaylor. display, data.event. JTableButtonEvent 

package mgtaylor . display . data . event ; 
import java . awt . event . ActionEvent ; 
import javax . swing . * ; 

public class JTableButtonEvent extends ActionEvent { 

private static final long serial VersionUID = 921553754034935026L ; 

private final JTable table ; 
private final int row; 

public JTableButtonEvent ( ActionEvent event , JTable table ) { 

super (event . getSource () , event . get ID ( ) , event . get ActionCommand ( ) 
event . get When () , event . getModi tiers () ) ; 
this. table = table; 

this. row = t able . get SelectedRow () ; 

} 

public int getRow() { return row; } 

public JTable getTableQ { return table; } 



D.5.15 mgtaylor. display.data.event. JTableButtonHandler 



i package mgtaylor . display . data . event ; 

3 public interface JTableButtonHandler { 

4 public void addTableButtonListener ( JTableButtonListener listener ); 

5 public void removeTableButtonListener ( JTableButtonListener listener ); 

6 public void fireTableButtonPressed ( JTableButtonEvent event ); 
r } 
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D.5.16 mgtaylor. display, data.event. JTableButtonListener 

package mgtaylor . display . data . event ; 

public interface JTableButtonListener { 

public void tableButtonPressed ( JTableButtonEvent event ); 

} 



D . 5 . 1 7 mgt ay lor . display, event . GraphDisplay Event 

package mgtaylor . display . event ; 

import java . awt . * ; 
import j ava . awt . geom . * ; 
import java. util .*; 

import mgtaylor . graph . * ; 

/** 
* 

* @author Martyn G Taylor 
* 

*/ 

public class GraphDisplayEvent extends AWTEvent { 

/* * * / 

private static final long serial VersionUID = - 1771309464704592206L ; 
private final Set<Vertex> vertices; 
private final Point2D . Double offset; 

private final Map<Vertex , Point2D . Double> offsetMap ; 

public GraphDisplayEvent ( Graph graph, Set<Vertex> vertices , Point2D . Double 
offset) { 

super(graph , 0) ; 
t his . v e r t i c e s = vertices; 
this . offset = offset; 
this . offsetMap = null; 

} 

public GraphDisplayEvent ( Graph graph, Set<Vertex> vertices , Map<Vertex , 
Point2D . Double> offsets) { 
super(graph, 0); 

30 t his . v e r t i c e s = vertices; 

31 this . offset = null ; 
this . offsetMap = offsets; 

} 

public Set<Vertex> get Vert i ces ( ) { 
return vertices; 

} 

public Point2D . Double getOffset ( Vertex vertex) { 
if (offset != null) 

return offset ; 
if (offsetMap != null) 

return offsetMap . get ( vertex ) ; 
return null ; 

} 
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D.5.18 mgtaylor. display, event. GraphDisplayHandler 

package mgtaylor . display . event ; 

public interface GraphDisplayHandler { 

public void addGraphDisplayListener ( GraphDisplayListener listener ); 
public void removeGraphDisplayListener ( GraphDisplayListener listener ); 
public void processGraphDisplayEvent ( GraphDisplayEvent event ); 

} 



D.5.19 mgtaylor. display, event. GraphDisplayListener 

package mgtaylor . display . event ; 
import java . util . EventListener ; 

public interface GraphDisplayListener extends EventListener { 

public void handleGrapliDisplayChanged ( GraphDisplayEvent event ) 

} 



D.5.20 mgtaylor. layout. ConstantMovementMap 

package mgtaylor . layout ; 

import j ava . awt . geom . * ; 
import j ava . util . * ; 

import mgtaylor . graph . Vertex ; 

public class ConstantMovementMap implements MovementMap { 
public final VertexLayout layout ; 
public final HashSet<Vertex> vertices; 
public final Point2D . Double offset; 

public ConstantMovementMap ( VertexLayout layout , HashSet<Vertex> vertices 
Point2D . Double offset) { 
this . layout = layout ; 
t his . v e r t i c e s = vertices; 
this . offset = offset; 

} 

©Override 

public VertexLayout getLayoutQ { 
return layout ; 

} 

©Override 

public Point2D . Double get VertexOffset ( Vertex vertex) { 
return offset ; 

} 

©Override 

30 public Point2D . Double getlnvertedVertexOffset ( Vertex vertex) { 

31 return new Point2D . Double ( — offset. x, — offset. y ); 

} 

34 ©Override 

35 public Set<Vertex> get Vert ices ( ) { 
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return vertices; 

} 

©Override 

public boolean cont ains ( Vertex vertex) { 
return ve r t i c e s . cont ains ( vertex ); 

} 



D . 5 . 2 1 mgt ay lor . layout . Movement Map 



i package mgtaylor . layout ; 

import j ava . awt . geom . * ; 
import java. util .*; 

import mgtaylor . graph . * ; 

public interface MovementMap { 

public VertexLayout getLayoutQ; 

public Set<Vertex> get Vert ices () ; 

public boolean contains ( Vertex vertex ); 

public Point2D . Double get VertexOffset ( Vertex vertex ); 

public Point2D . Double getlnvertedVertexOffset ( Vertex vertex ) 

} 



D.5.22 mgtaylor. layout. OrderedVertexLayout 

package mgtaylor . layout ; 

import java . awt . geom . Point2D ; 
import java . util . ArrayList ; 

import mgtaylor . graph . Graph ; 

import mgtaylor . graph . Vertex ; 

import mgtaylor . graph . Edge ; 

public class OrderedVertexLayout extends RandomVertexLayout { 

public Ordered VertexLayout ( Graph graph) { 
super ( graph ) ; 

} 

©Override 

public void performLayout ( ) { 

ArrayList <Vertex> vertices = getGraph (). get Vert i ces () ; 
Point2D . Double 11 = get VertexLocation ( ve r t i c e s . get ( ) ); 

11 .x = 50; 11 -y = 95; 

Point2D . Double 12 = get VertexLocation ( ve r t i c e s . get ( 1 ) ); 

12 .x = 95; 12 .y = 5; 

Point2D . Double 13 = get VertexLocation ( ve r t i c e s . get ( 2 ) ); 

13 .x = 5; 13 .y = 5; 

25 for ( int i = 3; i < vertices . size () ; i++ ) { 

26 Vertex v = ve r t i c e s . get ( i ); 
ArrayList <Edge> edges = v . getConnectedEdges ( ) ; 

Point2D . Double pll = get VertexLocation ( edges . get ( ) . getOtherEndFrom ( 

v ) ); 
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Point2D . Double pl2 = get VertexLocation ( edges . get ( 1 ) . getOtherEndFrom ( 

v ) ); 

Point2D . Double pl3 = get VertexLocation ( edges . get ( 2 ). getOtherEndFrom ( 

v ) ); 

Point2D . Double loc = get VertexLocation ( v ); 
loc.x = (pll.x + pl2.x + pl3.x)/3; 
loc.y = (pll.y + P 12.y + pl3.y)/3; 



D.5.23 mgtaylor. layout. PermutableFlippableLayout 



i package mgtaylor . layout ; 

import j ava . awt . geom . Point2D ; 
import java . util . ArrayList ; 

import mgtaylor . graph . Graph ; 

import mgtaylor . graph . Vertex ; 

import mgtaylor . graph . graphTypes . PermutableFlippableGraph ; 

public class PermutableFlippableLayout extends RandomVertexLayout { 

public PermutableFlippableLayout ( Graph graph) { 
super ( graph ) ; 

} 

©Override 

public void performLayout ( ) { 

if ( this . getGraph ( ) instanceof PermutableFlippableGraph ) { 

final PermutableFlippableGraph g = (PermutableFlippableGraph) 
this . getGraph () ; 

final ArrayList <Vertex> vertices = 
setLocation( vertices. get(O), 10.0, 
setLocation( vertices. get(l), 
setLocation( vertices. get ( 2 ) , 
final int s = v e r t i c e s . s i z e ( ) 
setLocation( vertices. get ( 3 ) , 
setLocation( vertices. get (4 ) , 
for ( int i = 3; i <= s ; i^+ ) 

setLocation( ve r t i c es . get ( i + 2) 

50.0 ); 



getVertices () ; 
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} 



} 



private void setLocation( Vertex vertex , double x, double y ) { 
Point2D . Double loc = get VertexLocation ( vertex ); 
loc.x = x ; 
loc . y = y ; 

} 



D.5.24 mgtaylor. layout. Planar WheelLayout 

f s 

i package mgtaylor . layout ; 

3 import java . awt . geom . Point2D ; 

4 import java. util .*; 
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import mgtaylor . graph . * ; 

import mgtaylor . graph . graphTypes . PlanarMultiWheelGraph ; 
import mgtaylor . graph . graphTypes . PlanarWheelGraph ; 

public class PlanarWheelLayout extends RandomVertexLayout { 

public PlanarWheelLayout ( Graph graph) { 
super ( graph ) ; 

} 

©Override 

public void performLayout ( ) { 

if ( this . getGraph ( ) instanceof PlanarWheelGraph ) { 

PlanarWheelGraph pwg = (PlanarWheelGraph) t his . get Graph () ; 
ArrayList<Vertex> rimVertices = pwg . get Rim Vert ices () ; 
switch ( r i m Vert ices . s i z e ( ) ) { 
case 0: 

return ; 
case 1 : 

setLocation( rimVertices. get(0), 50.0, 50.0 ); 
return ; 
case 2: 

setLocation( rimVertices. get(0), 25.0, 50.0 ); 
setLocation( rimVertices. get(l), 75.0, 50.0 ); 
return ; 
default : 

for ( int i = 0; i < rimVertices . size () ; i^+ ) { 

double angle = (40.0 * ( 2.0d * i / ( rim Vert ices . s i z e ( ) — 1) ) 
40. Od) * Math. PI / 180. Od; 
setLocation( rimVertices . get ( i ) , 

50.0 + 70. Od * Math.sin( angle ), 
-50 + 70. Od * Math, cos ( angle ) ); 

} 

} 

Vertex innerHub = pwg . getlnnerHubVertex ( ) ; 
if ( innerHub != null ) 

setLocation( innerHub, 50.0, 8.0 ); 
Vertex outerHub = pwg . getOuterHubVertex ( ) ; 
if ( outerHub != null ) 

setLocation( outerHub, 50.0, 95.0 ); 
} else if ( this . getGraph ( ) instanceof PlanarMultiWheelGraph ) { 

PlanarMultiWheelGraph pmwg = (PlanarMultiWheelGraph) this . getGraph ( ) 
Vertex center = pmwg. getCenter Vertex () ; 
if ( center != null ) { 

setLocation( center, 50.0, 50.0 ); 

Array List <Vertex> hubs = pmwg. getHubs ( ) ; 

ArrayList <ArrayList <Vertex» spokes = pmwg . get Spokes () ; 
final int numberOfSpokes = hubs, size (); 
double angle = 2.0d * Math. PI / numberOfSpokes; 
for ( int i = 0; i < numberOfSpokes; i++ ) { 
double hr = 35.0 * Math, cos ( angle / 2.0 ); 
setLocation( hubs . get ( i ) , 

50.0 + hr * Math.cos( angle * i - angle / 2.0 ), 
50.0 + hr * Math, sin ( angle * i - angle / 2.0 ) ); 
ArrayList <Vertex> spoke = spokes . get ( i ); 
for ( int s = 0; s < spoke . size () ; s++ ) { 
double r = 45.0 * (s + 1) / spoke . s i z e () ; 
setLocation( spoke . get ( s ) , 

5 0.0 + r * Math . cos ( angle * i ), 
5 0.0 + r * Math, sin ( angle * i ) ); 

} 

} 

} 

} else { 
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super . performLayout ( ) ; 

} 

} 

private void setLocation( Vertex vertex , double x, double y ) { 
Point2D . Double loc = get VertexLocation ( vertex ); 
loc . x = x ; 
loc .y = y ; 

} 



D.5.25 mgtaylor. layout. RandomVertexLayout 

i package mgtaylor . layout ; 

import j ava . awt . geom . Point2D ; 
import mgtaylor . graph . * ; 

public class RandomVertexLayout extends VertexLayout { 

public RandomVertexLayout ( Graph graph) { 
super ( graph ) ; 

} 

©Override 

public void performLayout ( ) { 

final int sz = get Graph () . vertexSize () ; 
for (int i = 0; i < sz ; i++ ) { 

final Vertex node = getGraph (). get Vert ices (). get ( i ) 
Point2D . Double loc = get VertexLocation ( node ) ; 
loc.x = 50 + 45 * Math, cos ( i * Math. PI * 2 / sz ) ; 
loc.y = 50 + 45 * Math, sin ( i * Math. PI * 2 / sz ); 



/* 



//*/ 
} 

} 



} 

for (final Vertex node: getGraph (). get Vert ic e s () ) { 
Point2D . Double loc = get VertexLocation ( node ) ; 
loc.x = Math . random ( ) * 100; 
loc.y = Math . random ( ) * 100; 

} 



D.5.26 mgtaylor. layout. TriangularPrismMaximalPlanarLayout 

package mgtaylor . layout ; 

import j ava . awt . geom . Point2D ; 
import j ava . u t i 1 . Array List ; 

import mgtaylor . graph . * ; 

public class TriangularPrismMaximalPlanarLayout extends VertexLayout { 

public TriangularPrismMaximalPlanarLayout ( Graph graph) { 
super ( graph ) ; 

} 
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©Override 

public void performLayout ( ) { 

16 final Array List <Vertex> vertices = getGraph (). get Vert ices () ; 

17 final boolean finishingExtra = ve r t i c es . s i z e ( ) % 3 > 1; 
final int i ; 

if ( v e r t i c e s . s i z e ( ) % 3 > ) { 

Point2D . Double loc = get VertexLocation ( ve r t i c es . get ( ) ); 
loc . x = 50. Od ; 
loc . y = 60. Od ; 

i = l; 
} else 

i = 0; 

final int sections = ve r t i c e s . s i z e ( ) / 3; 
final int ysize = sections + ( finishingExtra ? 1 : 0) ; 

28 for ( int s = l; S <= sections ; s^+ ) { 

29 Point2D . Double loc = get VertexLocation ( ve r t ic es . get ( s * 3 — 3 + i ) ) 
loc.x = 50. Od — s * 45. Od / sections; 
loc.y = 60. Od + s * 35. Od / sections; 

32 loc = get VertexLocation ( v e r t i ce s . ge t ( s * 3 — 2 + i ) ); 

33 loc.x = 50. Od + s * 45. Od / sections; 
loc.y = 60. Od + s * 35. Od / sections; 

loc = get VertexLocation ( v e r t i c e s . get ( s * 3 — 1 + i ) ); 

36 loc.x=50.0d; 

37 loc.y = 60. Od — s * 55. Od / ysize; 
} 

if ( finishingExtra ) { 

Point2D . Double loc = get Vert exLocat ion ( v e r t i c e s . get ( ve r t i c es . s i z e ( ) — 



} 



i)); 

loc.x = 50. Od ; 
loc.y = 5 . d ; 



D.5.27 mgtaylor. layout. VertexLayout 



package mgtaylor . layout ; 

import java. util .*; 
import j ava . awt . geom . * ; 

import mgtaylor . layout . event . * ; 

import mgtaylor . datastructures . LinkList ; 
import mgtaylor . graph . * ; 

public abstract class VertexLayout implements GraphLayoutHandler { 
private final Graph graph; 

private final VertexLayout previousLayout ; 

private final LinkList <GraphLayoutListener> listeners = new 
LinkList <GraphLayoutListener >() ; 

private final LinkList <MovementMap> history = new LinkList <MovementMap> () ; 
private final LinkList <MovementMap> undoHistory = new LinkList <MovementMap> () 

private final HashMap<Vertex , Point2D . Double> pointMap = new HashMap<Vertex , 
Point2D . Double >() ; 

public VertexLayout ( Graph graph) { 
this. graph = graph; 
this . previousLayout = null; 

for (Vertex vertex: graph . get Vert ices () ) { 
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pointMap . put ( vertex , new Point2D . Double ( , 0)); 

} 

performLayout ( ) ; 

} 

public VertexLayout ( VertexLayout previousLayout ) { 
this, graph = previousLayout . getGraph () ; 
this . previousLayout = previousLayout ; 
for (Vertex vertex: graph . get Vertices () ) { 

final Point2D . Double loc = new Point2D . Double ( , 0); 

final Point2D . Double prev = previousLayout . get VertexLocation ( vertex ) 

loc . x = prev . x ; 

loc .y = prev .y; 

pointMap . put ( vertex , loc); 

} 

performLayout ( ) ; 

} 

public Graph getGraph () { return graph; } 

public VertexLayout getPreviousLayout ( ) { return 

previousLayout ; } 

public Point2D . Double get VertexLocation ( final Vertex vertex) { 
return pointMap . get ( vertex ) ; 

} 

public Point2D . Double get VertexLocation ( final Vertex vertex, final 
Point2D . Double offset) { 

final Point2D . Double p = pointMap . get ( vertex ) ; 

if ( offset = null | | p = null ) 
return p; 

double x = Math.min( 100.0, Math.max( 0.0, p.x+ offset .x)); 
double y = Math.min( 100.0, Math.max( 0.0, p.y + offset, y) ) ; 
return new Point2D . Double ( x, y ); 

} 

public Point2D . Double get VertexLocation ( final Vertex vertex, final 
MovementMap map ) { 

if ( map ! = null &fe map . contains ( vertex )) 

return get VertexLocation ( vertex, map . get VertexOffset ( vertex ) ); 

return get VertexLocation ( vertex ); 

} 

public void processMovement ( MovementMap map ) { 
if ( this = map . getLayout ( ) ) { 
history . addHead (map) ; 
undoHistory . clear () ; 
moveVerticesBy ( map, false ); 

} 

} 

public boolean canUndoQ { return ! his t o r y . isEmpty ( ) ; } 
public boolean canRedoQ { return ! undoHistory . isEmpty () ; } 

public void undo ( ) { 
if ( canUndoQ ) { 

final MovementMap map = h is t or y . removeHead ( ) ; 
undoHistory . addHead ( map ); 
move VerticesBy ( map, true ) ; 

} 

} 

public void redo() { 
if ( canRedoQ ) { 

final MovementMap map = undoHistory . removeHead ( ) ; 
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history . addHead ( map ); 
moveVerticesBy ( map, false ); 

} 

} 

protected void moveVerticesBy ( MovementMap map, boolean invert ) { 
if ( this = map . getLayout ( ) ) { 

93 for ( Vertex vertex: map . get Vert i ces () ) 

94 if ( pointMap . containsKey ( vertex ) ) { 
if ( invert ) 

pointMap . put ( vertex , get VertexLocation ( vertex, 
map . getlnvertedVertexOffset (vertex) ) ) ; 
else 

pointMap . put ( vertex , get VertexLocation ( vertex, 
map . getVertexOffset (vertex) ) ) ; 
99 } 

ioo processGraphLayoutEvent ( new GraphLayoutEvent ( this, map )); 

} 



101 
102 



115 



117 



} 



protected void set VertexLocation ( final Vertex vertex, final Point2D . Double 
point ) { 

105 if ( pointMap . containsKey ( vertex ) ) 

ioo pointMap . remove ( vertex ) ; 

107 final Point2D . Double p = new Point2D . Double ( 

ios Math.min( 100.0, Math.max( 0.0, point, x) ) , 

109 Math.min( 100.0, Math.max( 0.0, point, y))); 

no pointMap . put ( vertex , p); 

in } 

public abstract void performLayout ( ) ; 



public void addGraphLayoutListener ( GraphLayoutListener listener ) { 



ii6 1 i s t e n e r s . addTail ( listener ); 



} 



119 public void removeGraphLayoutListener ( GraphLayoutListener listener ) { 

120 1 i s t e n e r s . remove ( listener ); 

} 

124 public void processGraphLayoutEvent ( GraphLayoutEvent event ) { 

125 for ( GraphLayoutListener listener: listeners ) 

126 listener. handleGraphL ay out Changed (event ) ; 

127 } 

128 ) 



D . 5 . 28 mgtaylor .layout .event .GraphLayoutEvent 

package mgtaylor . layout . event ; 
import java . awt . * ; 
import mgtaylor . layout . * ; 

/** 

* ©author Martyn G Taylor 

* 

* / 

public class GraphLayoutEvent extends AWTEvent { 
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} 



/* **/ 

private static final long serialVersionUID = - 1 771309464704592206L ; 
private final VertexLayout layout ; 
private final MovementMap map; 

public GraphLayoutEvent ( VertexLayout layout , MovementMap map) { 
super( layout , 0) ; 
this . layout = layout ; 
this, map = map ; 

} 

public VertexLayout getLayoutQ { 
return layout ; 

} 

public MovementMap getMovementMap ( ) { 
return map; 

} 



D . 5 . 29 mgtaylor .layout .event . GraphLayoutHandler 

i package mgtaylor . layout . event ; 

public interface GraphLayoutHandler { 

public void addGraphLayoutListener ( GraphLayoutListener listener ); 
public void removeGraphLayoutListener ( GraphLayoutListener listener ) 
public void processGraphLayoutEvent ( GraphLayoutEvent event ); 

} 



D . 5 . 30 mgtaylor .layout .event .GraphLayoutListener 

package mgtaylor . layout . event ; 
import java . util . EventListener ; 

public interface GraphLayoutListener extends EventListener { 

public void handleGraphLayoutChanged ( final GraphLayoutEvent event ); 

} 



D . 5 . 3 1 mgt ay lor . planar ity. event . Planar Or der Event 

/ 1 

i package mgtaylor . planarity . event ; 
3 import java.awt.*; 

5 import mgtaylor . display . PlanarityHandler ; 
7 import mgtaylor . graph . * ; 

9 public class PlanarOrderEvent extends AWTEvent { 

lo /* * * / 

n private static final long serialVersionUID = - 1002995001888288200L ; 

13 public PlanarOrderEvent ( PlanarityHandler test) { 

14 super ( test , 0) ; 
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} 

17 public Planarity Handler ge t P 1 anar i t y ( ) { 
is return ( PlanarityHandler ) getSourceQ; 

} 

21 public Edge[] getOrder( Vertex vertex ) { 

22 return vertex . getEdgeOrder () ; 

23 } 

24 } 



D . 5 . 32 mgtaylor .planarity. event . Planar OrderHandler 



i package mgtaylor . planarity . event ; 

3 public interface PlanarOrderHandler { 

4 public void addPlanarOrderListener ( PlanarOrderListener listener ); 

5 public void removePlanarOrderListener ( PlanarOrderListener listener ); 

6 public void processPlanarOrderEvent ( PlanarOrderEvent event ) ; 

■ } 



D . 5 . 33 mgtaylor .planarity. event .PlanarOrderListener 



i package mgtaylor . planarity . event ; 

3 public interface PlanarOrderListener { 

4 public void handlePlanarOrderChanged ( PlanarOrderEvent event ); 

* } 



D.5.34 mgtaylor. tools. Trigonometry 



package mgtaylor . tools ; 

/** 

* ©author Martyn Taylor 

* ©since 2004-11-15 

*/ 

public final class Trigonometry { 

/* * 

* Array to store cosine lookup values . 
* 

* ©see Trigonometry . cos 

*/ 

private static final double [] COSANGLES = new double [ 9 1 ] ; 

/** 

* Array to store cosine lookup values . 

17 * 

is * ©see Trigonometry . s i n 

* / 

private static final double [] SINANGLES = new double [ 9 1 ] ; 

/ * * 

* Array to store cosine lookup values . 



2-1 
25 
26 
27 

29 
30 
31 
32 
33 
34 

36 
37 
38 
39 
40 
-11 

43 
44 
45 
46 
47 
48 

50 
51 
52 
53 
54 
55 
56 
57 
58 
59 
60 
61 
02 
63 
64 

66 
07 
68 
69 
70 
71 
72 
73 
74 
75 
76 
77 
78 
79 

81 
82 
83 
84 
85 
SO 
37 
33 



APPENDIX D. JAVA SOURCE CODE 414 



* @see Trigonometry . tan 

*/ 

private static final double[] TANANGLES = new double [ 9 1 ] ; 

/** 

* Array to store cosine lookup values . 
* 

* ©see Trigonometry . arccos 

* / 

private static final double [] ARCCOSANGLES = new double [9 0]; 

/ * * 

* Array to store cosine lookup values . 
* 

* ©see Trigonometry . arcsin 

* / 

private static final double [] ARCSINANGLES = new double [ 9 ] ; 

/* * 

* Array to store cosine lookup values . 
* 

* Osee Trigonometry . arctan 

* / 

private static final double[] ARCTANANGLES = new double [ 9 ] ; 

/* * 

* Static block to initialise lookup arrays defined above. 

* / 

static { 

for ( int i = 0; i <= 90; i++ ) { 

COSANGLES [ i ] = Math, cos ( Math . toRadians ( i ) ); 
SINANGLES [ i ] =Math.sin( Math . toRadians ( i ) ); 
TANANGLES [ i ] = Math, tan ( Math . toRadians ( i ) ); 

} 

for ( int i = 0; i < 90; i++ ) { 

ARCCOSANGLES [ i ] = Math, cos ( Math . toRadians ( i + 0.5d ) ) 
ARCSINANGLES [ i ] = Math, sin ( Math . toRadians ( i + 0.5d ) ) 
ARCTANANGLES [ i ] = Math, tan ( Math . toRadians ( i + 0.5d ) ) 

} 

} 

/** 

* Search thourgh the lookup table to find the closest integer 

* value of arccos(cos) and returns the associated angle. 

* 

* arccos (cos) takes arguments between —1 and 1 and returns 

* angles between Of and 180f and an invalid input will return 

* -1. 

* 

* ©param cos double 

* ©return int 

*/ 

public static final int arccos (double cos) { 
if (cos > 1 || cos < —1) 
return — 1; 

double c = Math . abs ( cos ) ; 
if (c >= ARCCOSANGLES[0]) 
if (cos < 0) { 
return 180; 
} else { 

return 0; 

} 

int min = 0; 
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int max = 90; 
while (min + 1 < max) { 

int mid = (min + max) »> 1; 

92 if (c >= ARCCOSANGLES [ mid ] ) max = mid; 

93 else min = mid; 
} 

if (cos < 0) { 

96 return 180 — max; 

97 } else { 
return max; 

} 



102 /* 

103 * arccos(x, y) calls arccos(cos) using cos = y/sqrt(xs + ys ) 

104 * and then determines the angle based on values of x and y. 

105 * 

* arccos(x, y) returns values between Of and 359f where Of 

* is vertical and increments clockwise. 



106 
107 

108 */ 

109 /* 

no public static final int arccos ( double x, double y) { 
in double r = Math . sqrt (x*x + y*y) 

112 if (r = 0) 

113 return 0; 

int angle = arccos (y/r) 

117 if (x < 0) { 

us 

119 



return (360 - angle)%360; 
} else { 



120 return angle ; 

121 } 

122 } 

123 / / * / 

125 / * * 

126 * Search thourgh the lookup table to find the closest integer 

127 * value of arcsin(sin) and returns the associated angle. 

128 * 

129 * arcsin(sin) takes arguments between —1 and 1 and returns 

130 * angles between — 90r and 90f and an invalid input will return 

131 * -100. 

132 * 

133 * @param sin double 

134 * ©return int 

135 */ 

136 public static final int arcsin (double sin) { 

137 if (sin > 1 || sin < —1) 

138 return —100; 

140 double s = Math . abs ( sin ) ; 

141 if (s < ARCSINANGLES [ ] ) 

142 return 0; 

143 int min = 0; 

144 int max = 90; 

145 while (min + 1 < max) { 

146 int mid = (min + max) »> 1; 

147 if (s < ARCSINANGLES [ mid ] ) max = mid; 

148 else min = mid; 

149 } 

150 if (sin < 0) { 

151 return —max; 

152 } else { 

153 return max; 
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154 




} 


155 




} 


157 


/* 




158 


* 


arcsin (x , y) calls arcsin(sin) using sin = x/sqrt (xs + ys 


159 


* 


and then determines the angle based on values of x and y. 


160 


* 




161 


* 


arcsin (x, y) returns values between Of and 359f where Of 


162 


* 


is vertical and increments clockwise. 


163 


*/ 




164 


/* 




165 




public static final int arcsin ( double x, double y) { 


166 




double r = Math . sqrt (x*x + y*y) ; 


167 




if (r = 0) 






r p 1 ii r n fl" 
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169 




int angle = arcsin(x/r); 


171 




if (y < 0) { 


172 




angle = 180 — angle ; 


173 




} else if (angle < 0) { 


174 




angle += 360; 


175 




} 


176 




return angle ; 


177 




} 


178 


//* 


/ 


180 


/** 




181 


* 


Search through the lookup table to find the closest integ 


182 


* 


value of arctan(tan) and return the associated angle. 


183 


* 




184 


* 


arctan(tan) returns values between s90f . 


185 


* 




186 


* 


@param tan double 


187 


* 


©return int 


188 






189 




public static final int arctan (double tan) { 


190 




double t = Math . abs ( tan ) ; 


191 




if (t < ARCTANANGLES [ ] ) 


192 




return 0; 


193 




int min = 0; 
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195 




while (min + 1 < max) { 


196 




int mid = (min + max) »> 1; 


197 




if (t < ARCTANANGLES [ mid ] ) max = mid; 


198 




else min = mid; 


199 




} 


200 




if (tan < 0) 


201 




return —max; 


202 




else 


203 




return max; 


204 




} 


206 


/* * 




207 


* 


arctan(x, y) calls arctan(tan) using tan = y/x 


208 


* 


and then determines the angle based on values of x and y. 


209 


* 




210 


* 


arctan(x, y) returns values between Of and 359f where Of 


211 


* 


is vertical and increments clockwise. 


212 


* 




213 


* 


@param x double 


214 


* 


@param y double 


215 


* 


@return int 


216 


*/ 




217 




public static final int arctan (double x, double y) { 


218 




if (x = 0) { 
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219 if (y < 0) return 180; 

220 return 0; 

221 } 

222 if (y = 0) { 

223 if (x > 0) return 90; 

224 return 270; 

225 } 

226 int tan = arctan(x/y); 

227 if (y < 0) { 

228 return tan + 180; 

229 } else if (tan < 0) { 

230 return tan + 360; 

231 } else { 

232 return tan ; 

233 } 

234 / * 

235 double tan = Math . abs ( x/y ) ; 

236 int min = 0, max = 90; 

237 while (min + 1 < max) { 

238 int mid = (min + max) » 1; 

239 if (tan < ARCTANANGLES [ mid ] ) max = mid; 

240 else min = mid; 

241 } 

242 if ((min = 0) && (tan < ARCTANANGLES [ ] ) ) max = 0; 

243 return ( x>0) ? ( y >0?max: 180 -max) : ( ( y >0) ? (max==0?0:360-max) :(180 + max) ) 

244 // */ 

245 } 

246 / * * 

247 * Returns the value of cosine from the lookup table. 

248 * 

249 * @param angle int 

250 * ©return double 

251 */ 

252 public static final double cos(int angle) { 

253 
254 
255 
256 
257 
258 
259 
260 

261 return COSANGLES[360 - angle ] ; 

262 } 

263 / * * 

264 * Returns the value of sine from the lookup table 

265 * 

266 * Oparam angle int 

267 * Oreturn double 

268 * / 

269 public static final double sin(int angle) { 

270 
271 
272 
273 
274 
275 
276 
277 

278 return -SINANGLES[360 - angle ] ; 

279 } 

280 / * * 

281 * Returns the value of tangent from the lookup table 

282 * 

283 * @param angle int 
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* ©return double 

*/ 

public static final double tan(int angle) { 
if (angle >= 0) { 

angle = angle % 180; 
} else { 

angle = (angle % 180) + 180; 

} 

if (angle <= 90) return TANANGLES [ angle ] ; 

return -TANANGLES[180- angle 

} 



} 
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D.6 r^TfrjX Segment Hierarchy Generation 



D.6.1 mgtaylor. latex. SegmentHierarchies 

< 

package mgtaylor . latex ; 

import mgtaylor . datastructures . UnmodifiableLinkList ; 
import mgtaylor . graph . Graph ; 
import mgtaylor . graph . Segment ; 

public class SegmentHierarchies { 



* Oparam args 

* / 

public static void main ( St ring [ ] args) { 
Graph g ; 

StringBuffer structure; 
int minSize ; 

structure = new StringBuffer () ; 
is structure . append ( " \\ begin{ tabular x }{\\ t extwidth }{ ccc }\n " ); 

19 minSize = 10; 

for (int i = 0; i < 3; i++ ) { 
structure . append( 

" \ t\\ set length {\\ unit HI . 2\\ par skip }\n\t \\ beg in {t ikzp i cture }\n " ) ; 
g = new mgtaylor . graph . graphTypes . PlanarMultiW heelGraph ( minSize + 3 * 
i , 3 , true ) ; 

g.DFS( g. getVertices () . get (0) ); 
g.generateSegmentsQ ; 

UnmodifiableLinkList <Segment> ss = g . getSegments ( ) ; 
j a va . u t i 1 . HashMap<Segment , j ava . lang . Character > sm = new 
j ava . u t i 1 . HashMap<Segment , java. lang. Character >(); 
char c = ' A ' ; 
for ( Segment s : ss ) { 

sm.put(s, new j ava . lang . Character ( c ) ); 
if (c = ' Z 1 ) 
c = ' a ' ; 

32 else 

33 C++; 
} 

ss . get Head () .toLaTeXString(structure , sm , 0, 0, false); 

36 structure . append ( " \t \\ end{ t ikzpi cture }\n " ); 

37 if ( i != 2 ) 
structure . append ( "&\n" ); 

else 

structure . append ( " Wtabularnewline \n" ); 

} 

for (int i = 0; i < 3; i++ ) { 
structure . append ( "\t(" ); 
structure . append ( (char) ('a' + i) ); 
structure . append ( ") " ); 
structure . append ( minSize + 3 * i ); 
structure . append ( " Vertices\n" ); 

48 if ( i != 2 ) 

49 structure . append ( "&\n" ); 
else 

structure . append ( " Wtabularnewline \n" ); 

52 } 

53 structure. append ("\\end{tabularx}\n") ; 
System . out . println ( structure ); 

structure = new StringBuffer () ; 
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62 
63 



69 
70 



81 
82 



85 
86 



89 
90 



structure . append ( " \\ begin{ tabular x }{\\ t extwidth }{ ccc }\n " ); 
minSize = 10; 

for (int i = 0; i < 3; i++ ) { 
structure . append( 

" \ t \ \ set length {\\ unit }{1.2\\parskip}\n\t\\begin{tikzpicture}\n") ; 

g = new mgtaylor . graph . graphTypes . PlanarMultiWheelGraph ( minSize + 3 * 

i , 3 , true ) ; 

g.DFS( g . get Vert ices (). get ( g . get Vert ices (). s i z e ()— 1) ); 
g.generateSegmentsQ ; 

UnmodifiableLinkList <Segment> ss = g . getSegments ( ) ; 

j ava . u t i 1 . HashMap<Segment , j ava . lang . Character > sm = new 

j ava . u t i 1 . HashMap<Segment , java. lang. Char acter>(); 

char c = ' A ' ; 

for ( Segment s : ss ) { 

sm.put(s, new j ava . lang . Character ( c ) ); 
if (c = ' Z 1 ) 

c = ' a 1 ; 
else 

C++; 

} 

ss . get Head ( ) . toLaTeXString (structure , sm , 0, 0, false); 
structure . append ( " \t \\ end{ t ikzpi ctur e }\n " ); 
if ( i != 2 ) 

structure . append ( "&\n" ); 
else 

structure . append ( " Wtabularnewline \n" ); 

} 

for (int i = 0; i < 3; i++ ) { 
structure . append ( "\t(" ); 
structure . append ( (char) ('a' + i) ); 
structure . append ( ") " ); 
structure . append ( minSize + 3 * i ); 
structure . append ( " Vertices\n" ); 
if ( i != 2 ) 

structure . append ( "&\n" ); 
else 

structure . append ( " \\ t abularnewl ine \n " ); 

} 

structure . append ("\\end{tabularx}\n") ; 
System . out . println ( structure ); 



98 
99 



101 
102 
103 
104 

105 
106 
107 
108 
109 
110 
111 
112 
113 
114 



structure = new StringBuffer () ; 

structure . append ( " \\ begin{ tabular x }{\\ t extwidth }{ ccc }\n " ); 
minSize = 9; 

for (int i = 0; i < 3; i++ ) { 
structure . append( 

" \ t\\ set length {\\ unit HI . 2\\ par skip }\n\t \\ begin{t ikzp i ctur e }\n " ) ; 
g = new 

mgtaylor . graph . graphTypes . TriangularPrismMaximalPlanarGraph ( minSize + 3 
* 1 ) i 

g.DFS( g . get Vertices () . get (0) ); 
g . generateSegments ( ) ; 

UnmodifiableLinkList <Segment> ss = g . getSegments () ; 

j ava . u t i 1 . HashMap<Segment , j ava . lang . Character > sm = new 

j ava . u t i 1 . HashMap<Segment , java. lang. Character >(); 

char c = ' A ' ; 

for ( Segment s : ss ) { 

sm.put(s, new j ava . lang . Character ( c ) ); 
if (c = 1 Z 1 ) 

c = ' a 1 ; 
else 

C++; 

} 

ss . get Head () .toLaTeXString(structure , sm , 0, 0, false); 
structure . append ( " \t \\ end{ t ikzpi ctur e }\n " ); 
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115 if ( i != 2 ) 

116 structure . append ( "fc\n" ); 

117 else 

us structure . append ( " \\ t abularnewl ine \n " ); 

119 } 

120 for (int i = 0; i < 3; i++ ) { 

121 structure . append ( "\t(" ); 

122 structure . append ( (char) ('a' + i) ); 

123 structure . append ( ") " ); 

124 structure . append ( minSize + 3 * i ); 

125 structure . append ( " Vertices\n" ); 

126 if ( i != 2 ) 

127 structure . append ( "&\n" ); 

128 else 

129 structure . append ( " \\ t abularnewl ine \n " ); 

130 } 

131 structure. append ("\\end{tabularx}\n") ; 

132 System . out . println ( structure ); 

134 structure = new StringBuffer () ; 

135 structure . append ( " \\ begin{ t abular x }{\\ t extwidth }{ ccc }\n " ); 

136 minSize = 9; 

137 for (int i = 0; i < 3; i++ ) { 

138 structure . append ( 

" \ t \ \ set length {\ \ unit Ml .2\\parskip}\n\t\\begin{tikzpicture}\n") ; 

139 g = new 

mgtaylor . graph . graphTypes . TriangularPrismMaximalPlanarGraph ( minSize + 3 

* i ) ; 

140 g.DFS( g . get Vert ices (). get ( g . get Vert ices (). s i z e ( ) — 1) ); 

141 g . generateSegments ( ) ; 

142 UnmodifiableLinkList <Segment> ss = g . getSegments ( ) ; 

143 j a va . u t i 1 . HashMap<Segment , j ava . lang . Character > sm = new 
j a va . u t i 1 . HashMap<Segment , java. lang. Char acter>(); 

144 char c = 1 A ' ; 

145 for ( Segment s : ss ) { 

146 sm. put (s , new j ava . lang . Character ( c ) ); 

147 if (c = ' Z 1 ) 

148 c = 1 a ' ; 

149 else 

150 C++; 

151 } 

152 ss . get Head ( ) . toLaTeXString (structure , sm , 0, 0, false); 

153 structure . append ( " \t \\ end{ t ikzpi ctur e }\n " ); 

154 if ( i != 2 ) 

155 structure . append ( "&\n" ); 

156 else 

157 structure . append ( " \\ t abularnewl ine \n " ); 

158 } 

159 for (int i = 0; i < 3; i++ ) { 

160 structure . append ( "\t(" ); 

161 structure . append ( (char) ('a' + i) ); 

162 structure . append ( ") " ); 

163 structure . append ( minSize + 3 * i ); 

164 structure . append ( " Vertices\n" ); 

165 if ( i != 2 ) 

166 structure . append ( "&\n" ); 

167 else 

168 structure . append ( " \\ t abularnewl ine \n " ); 

169 } 

170 structure. append ("\\end{tabularx}\n") ; 

171 System . out . println ( structure ); 

172 } 
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E.l Matlab Code to Load Data 



Listing E.l.l: Loading Code Warm-Up Data (see section 6.3.2) 

data, warmup. triangular = loadGraphData ( [] , 

'CodeWarmUp-Triangle\DifferentRoot-Triangle- ' , { '50', '250', '250a', '250b', 
'500', '500a', '750', '750a', '1000', '1000a', '1250', '1250a', '1500' }, 'root' 

); 

data. warmup. wheel = loadGraphData ( [] , ' CodeWarmUp - Wheel \Dif f erentRo ot - ' , { 
'250', '500', '750', '1000', '1250', '1500', '2000', '2500' }, 'root' ); 



Listing E.l. 2: Loading Different Roots Data 



d at a . r o o t s . t r i an g u 1 ar = loadAndSplitGraphData ( [] , 

' Dif f erentRoots -Triangle\Dif f erentRoot -Triangle - 1 , '250,750,1001,1002' , 'root' 

'vertex', { 250, 750, 1001, 1002 }, { '250', '750', '1001', '1002' } ); 

d at a . r o o t s . t r i ang u 1 ar = loadGraphData ( d a t a . r oo t s . t r i a ng u 1 ar , 

' Dif f erentRoots - Tri angle \ Dif f erentRoot -Triangle -' , { '500', '1000', '1250', 

'1500' }, 'root' ); 

dat a . r oo t s . w hee 1 = loadAndSplitGraphData ( [] , 

' Dif f erentRoots -Wheel\Diff erentRoot -Wheel- ' , '250,500,750,1000' , 'root' , 
'vertex', { 250, 500, 750, 1000 }, { '250', '500', '750', '1000' } ); 
d at a . root s . wheel = loadGraphData ( dat a . root s . wheel , 

' Dif f erentRoots-Wheel\Dif f erent Root - Wheel - ' , { '1250', '1500' }, 'root' ); 

dat a . root s . ordered = loadAndSplitGraphData ( [] , 

' Dif f erentRoots - Order ed\D if f erentRoot - Ordered- ' , '250,500,750,1000,1250' , 
'root', 'vertex', { 250, 500, 750, 1000, 1250 }, { '250', '500', '750', '1000'. 
' 1250 ' } ) ; 

dat a . r oot s . or der ed = loadAndSplitGraphData ( dat a . r oot s . or der e d , 

' Dif f erentRoots - Order ed\ D if f erentRoot - Ordered- ' , '1500,2000', 'root', 'vertex' 
{ 1500, 2000 }, { '1500', '2000' } ); 

data. roots. random = loadAndSplitGraphData ( [] , ' D i f f erent Root s - Random\Random - ' 
'250,500,750,1000', 'root', 'vertex', { 250, 500, 750, 1000 }, { '250', '500', 
' 750 ' , ' 1000 ' } ) ; 

data. roots. random = loadGraphData ( dat a . root s . random , 

' Dif f erentRoots-Random\Random- ' , { '1250', '1500' }, 'root' ); 

data. roots. random = loadGraphData ( [] , ' Dif f erent Root s - Random\ Random - ' , { '250' 
'500', '750', '1000', '1250', '1500' }, 'root' ); 
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Listing E.1.3: Loading Different Sizes (42-4500 Vertices) Data 

d at a . ss i z e s . or d e r e d = loadGraphData ( [] , ' D i f f er ent S ize s \ Or der ed - 42 - 4500 - 1 , { 
'0', ' N ' , 'N4', 'N2', '3N4' }, 'vertex' ); 

d at a . ssizes . r andom = loadGraphData ( [] , ' Dif f er ent S i zes \ Random - 42 - 4500 - ' , { '0' , 

' N ' , 'N4', 'N2', '3N4' }, 'vertex' ); 

d a t a . s s i z e s . t r i a n g u 1 ar = loadGraphData ( [] , 

' Dif f erentSizes\Triangular-42-4500- ' , { '0', ' N ' , ' N4 ' , ' N2 ' , ' 3N4 ' }, 'vertex' 

); 

d a t a . s s i z e s . w he e 1 = loadGraphData ( [] , ' Dif f er ent S izes \ Wheel - 40 - 4500 - ' , { '0' , 
' N ' , 'N4', 'N2', '3N4' }, 'vertex' ); 



Listing E.1.4: Loading Different Sizes (500-15000 Vertices) Data 

d a t a . s i z e s . o r de r e d = loadGraphData ( [] , ' D if f er ent S i zes \ Or der ed - 50 1 - 1 5000 - ' , { 
'0', ' N ' , 'N4', 'N2', '3N4' }, 'vertex' ); 

dat a . sizes . r andom = loadGraphData ( [] , ' D if f er ent S izes \ Random - 502 - 15000 - ' , { 
'0', ' N ' , 'N4', 'N2', '3N4' }, 'vertex' ); 
d a t a . s i z e s . t r i a ng u 1 a r = loadGraphData ( [] , 

' Dif f erentSizes\Triangular-501 - 15000- ' , { '0', ' N ' , ' N4 1 , ' N2 ' , ' 3N4 ' }, 
1 vertex ' ) ; 

d a t a . si z es . whe e 1 = loadGraphData ( [] , ' Dif f er ent S ize s \ Wheel - 502 - 1 5000 - ' , { '0' , 
' N ' , 'N4', 'N2', '3N4' }, 'vertex' ); 



Listing E.1.5: Loading Different Edges Data 

d at a . e dge s . t r i angu lar = loadGraphData ( [] , 

' Dif f erentEdges\Biconnected\Triangular- ' , { '0', ' N4 ' , ' N4a ' , ' N2 ' , '3N4', ' N ' 
} , ' edge ' ) ; 

d at a . edges . wheel = loadGraphData ( [] , ' Dif f erentEdges \Biconnected\Wheel - ' , { 
'0', 'N4', 'N2', '3N4', ' N ' }, 'edge' ); 

d at a . edges . or der ed = loadGraphData ( [] , ' Dif f erentEdges \ B i conne ct ed \ Or der ed - ' , { 
'0', 'N4', 'N4a', ' N2 ' , ' 3N4 ' , ' N ' }, 'edge' ); 

data. edges. random = loadGraphData ( [] , ' Dif f erentEdges \ B i c onne ct ed \ Random - ' , { 
'0', 'N4', 'N2', '3N4', ' N ' }, 'edge' ); 



E.2 Matlab Code To Generate Figures 



Figure Matlab Code 



6.3.1 


1 
2 
3 


r 

PlotShowCodeWarmUp ( data. warmup. triangular. sl250 , ... 
'1250 Vertex Triangular Graph 1 , ... 
'showbetween', [1 1], 1 ypercentile 1 , 98, ... 






4 


'usesubplot 1 , true ) ; 


) 



1 PlotShowCodeWarmUp ( data. warmup. triangular. sl250 , ... 

2 ' 1250 Vertex Triangular Graph ' , ' showbetween ' , [2 2] ) ; 

v > 
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Figure Matlab Code 



xl = normrnd (0 ,1,50,1); x2 = normrnd(0 .1 ,0.9,100,1); 
binEdges = [-inf ; sort ( [ xl ; x2 ] ) ; inf ] ; 
binCountsl = histc (xl , binEdges , 1) ; 
binCounts2 = histc (x2 , binEdges , 1) ; 
sumCountsl = cumsum( binCountsl ). /sum( binCountsl ) ; 
sumCounts2 = cumsum( binCounts2 ) . /sum( binCounts2 ) ; 
ks = abs ( sumCountsl - sumCounts2 ) ; 

x = [binEdges sumCountsl sumCounts2 ] ; x (any ( ( ks ~=max( ks ) ) , 2) 



=1 



figure; stairs ( binEdges, sumCountsl 
sumCounts2 , 'b- ' ) ; 
arrow( [x(l) x(2)], [x(l) x(3)] 
arrow( ]x(l) x(3)j, ]x(l) x(2)j 
xlabel ( ' x ' ) 
ylabel ( 1 ECDF (x) 1 ) 
legend( '~N(0,1)', '~N(0.1,0.9) 



); hold on; stairs ( binEdges, 



4 ,90 ,30 ,1) 
4 ,90 ,30 ,1) 



Location 1 



'best' ) 



title ( {'Empirical Cumulative Density Function of Two Randomly' , 
'Generated Distributions Approximating N(0,1) and N (0 . 1 , . 9) ' } ); 



arrow. m is available from: http://www.mathworks.com/matlabcentral/fileexchange/278 



screenSize = get (0 , ' ScreenSize ' ) ; 

fig = figure( 'Position', [0 screenSize(3) screenSize (4)], 

' PaperUnits ' , 'inches', ' PaperPos it ion ' , [0 10 7], 'Color', 'white'); 

subplot (2,2,1), 

PlotNumberOfElements ( d a t a . s i z es . whe e 1 . s , { 'Planar Wheel Graph - 

Number of' , 'Data Points Uninterrupted by Garbage Collection' }, 

' showasbar ' , false , 'newfigure' , false ) 

axis( [0 15000 70 100]) ; 
subplot (2,2,2), 

PlotNumberOfElements ( d a t a . s i z e s . t r i an g u 1 a r . s , { 'Triangular Prism 

Graph - Number of' , 'Data Points Uninterrupted by Garbage Collection' }, 

'showasbar' , false , 'newfigure' , false ) 

subplot (2,2,3), 

PlotNumberOfElements ( d a t a . s iz es . or der ed . s , { 'Ordered Face 
Trisection Graph - Number of' , 'Data Points Uninterrupted by Garbage 
Collection' }, 'showasbar' , false , 'newfigure' , false ) 
axis ( [0 15000 70 100]) ; 

subplot (2,2,4), 

PlotNumberOfElements ( dat a . s iz es . r ando m . sO , { 'Random Face Trisection 
Graph - Number of' , 'Data Points Uninterrupted by Garbage Collection' 
}, 'showasbar', false, 'newfigure', false ) 
axis ( [0 15000 70 100]) ; 

print ( fig , '-dpng' , 

' Images / Benchmarking / Number Of NonGCEl ement s-Size-lstRoot.png', 1 - r 150 1 ); 



6.4.1 


1 


f 

x = (- 10:10) '; 








2 


y = 2*x. "3 - 38*x +19; 








3 


y(21) = 0; 








4 


bf = fitdata2 ( x , y , { ' x3 ' , 


{ ' x3 ' , ' x2 ' } , { ' x3 ' , ' x2 ' , ' x ' } } , 








' user obustf it ' , false ) ; 








5 


figure ; hold all ; 








6 


plot ( x, y, '+' , 'MarkerSize 


, 3 , ' DisplayName ' , ' Data ' ) ; 






7 


fn = fieldnames ( bf. data ) ; 








8 


for f = 1 : numel ( f n ) , 








9 


plot ( unique(x) , bf.data 


(fn{f }) , '-', 'DisplayName', 








bf. equation. (fn{f}) ); 








10 


end ; 








11 


legend( 'show' , 'Location' , 


best ' ) ; 






12 


bf . rmse 








13 


bf.mae 














J 
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Figure Matlab Code 



6.4.2 



A. 1.1, 
A. 1.2, 
A. 1.3, 
7.4.2, 
A. 1.4, 
A. 1.5, 
A. 1.6, 
A. 1.7, 
A. 1.8, 
7.4.3, 
A. 1.9, 
A. 1.10, 
A. 1.11, 
A. 1.12, 
A. 1.13, 
7.4.4, 
A. 1.14, 
A. 1.15, 
A. 1.16, 
A. 1.17, 
A. 1.18, 
A. 1.19, 
7.4.5, 
A. 1.20 
and 
A. 1.21 

7.4.6 



x = (- 10:10) '; 

y = 2*x. ~3 - 38*x + 19; 

y(21) = 0; 

bf=fitdata2(x, y, { ' x3 ' , {'x3','x2'}, ... 

{ 'x3', 'x2', 'x' } }, 'userobustfit 1 , true ); 
figure ; hold all ; 

plot( x, y, '+', ' MarkerSize ' , 3, 'Display Name', 'Data' ) 
fn = f ieldnames ( bf . d at a ) ; 
for f = 1 : numel ( fn ) , 

plot ( unique(x), bf.data.(fn{f}), '-', ... 
'DisplayName', bf. equation. ( f n { f } ) ); 

end ; 

legend ( 'show', 'Location', 'best' ); 

bf . rmse 
bf . mae 



g.t. triangular 
g.t .random 
g.t. ordered 
g . t . whee 1 
g.m. triangular 
g.m. random 
g.m. ordered 
g.m. wheel 



= 'Triangular Prism' ; 
= 'Random Face Trisection' ; 
= 'Ordered Face Trisection'; 
= ' Planar Wheel ' ; 

= true ; 
= false ; 
= false ; 
= false ; 
n = fieldnames ( data. roots ) ; 
for i=l:numel(n) , 

r = fieldnames ( d at a . r oo t s . ( n{ i } ) ); 
for j=l:numel(r) , 

plot GraphData ( data. roots. (n{i}).(r{j}), [r{j}(2: numel ( r { j } ) ) ' 
Vertex ' g.t.(n{i}) ' Graph '], 'percentile', 98, 

'percentilesteps', 25, 'showbandsinlegend', true, 'lowcolour 1 , [0 
1], 'high colour', [0 1 0], 'usehsl', true, 'mapx', g.m.(n{i}), 
'save 1 , ['DifferentRootsV upper ( n{ i } ( 1 ) ) lower ( 

n{i}(2:numel(n{i}))) '-' r { j } ( 2 : numel ( r { j } ) ) ] ); 

end 

end 



plotGraphData ( dat a . root s . random . s 1 000a , '1000 Vertex Random Face 

Trisection Graphs ', 'percentile', 98, 'percentilesteps', 25, 

' showbandsinlegend ', false, 'lowcolour', [0 1], 'highcolour', [0 1 

'usehsl', true, 'showdepthsbestfit', false, 'showbestfits', false ); 

plotGraphData ( dat a. root s . random . s 1 000 , '1000 Vertex Random Face 

Trisection Graphs ', 'percentile', 98, 'percentilesteps', 25, 

' showbands inlegend ', false, 'lowcolour', [0 0], 'highcolour', [1 

'usehsl', true, 'showdepthsbestfit', false, 'showbestfits', false, 

'newfigure', false ); 

print ( gcf , '-dpng' , ' DifferentRoots \Random- 1000a , 1000 - Overlay . png ' , 
' -rl50 ' ) ; 



0] 



0] 
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Figure 


7.5.1, 


1 


A.2.1, 




A. 2. 2, 


3 


A. 2. 3, 


4 


A. 2.4, 


5 


7.5.2, 


6 
7 


A. 2. 10, 




A. 2. 11, 


9 


A. 2. 12, 


10 


A. 2. 13, 


11 


A. 2. 14, 


12 
13 


7.5.3, 




A.2.26, 




A.2.27, 




A.2.28, 




A.2.29, 




7.5.4, 


15 


A.2.35, 


16 


A.2.36, 




A.2.37 




and 




A.2.38 




A.2.15 


1 



Mat lab Code 



'Triangular Prism' ; 
'Random Face Trisection'; 
'Ordered Face Trisection 1 
' Planar Wheel ' ; 

' 1st ' ; 
' i/4 Nth ' 
' 1/2 Nth ' 
' 3/4Nth ' 
' Nth ' ; 



gnm. title. triangular 

gnm. title. random 

gnm. title. ordered 

gnm. title. wheel 

gnm. root. sO 

gnm.root.sN4 

gnm. root . sN2 

gnm. root. s3N4 

gnm. root .sN 

gn = fieldnames( data.ssizes ); 

for i = 1 : numel ( gn ) , 

rn = fieldnames ( d a t a . s s i z e s . ( gn{ i } ) ); 
for j =1: numel ( rn ) , 

plotGraphData( data.ssizes. ( gn{ i } ) . (rn{j}) , [gnm. title. ( gn{ i } ) 
Graph (Root = ' gnm. root. (rn{j}) ')'], 'percentile', 100, 
' per cent i lest eps ' , 100, ' showbandsinlegend ' , false , 
'showdepthsbestfit', true, 'save', ['DifferentSizesV upper ( 
gn{i}(l) ) lower ( gn{ i } (2 : numel (gn{ i }) ) ) '-Small-' 
rn{ j } (2 : numel( rn{ j }) ) ] ); 

end 

end 



plotGraphData ( d at a . ss i z es . w h e e 1 . s , 'Planar Wheel Graph (Root = 1st, 
Vertices > 750)', 'percentile', 100, 'percentilesteps', 100, 
'showbandsinlegend' , false , 'showdepthsbestfit' , false , 'save' , 
' Dif f erentSizes\Wheel-Small-0-750 ' , 'betweenx', [750 4500] ); 




plotGraphData ( d at a . ssizes . wheel . s N 4 , 'Planar Wheel Graph (Root = i/4Nth . 
Vertices > 750)', 'percentile', 100, 'percentilesteps', 100, 
'showbandsinlegend' , false , 'showdepthsbestfit' , false , 'save' , 
' Dif f erentSizes\Wheel-Small-N4-750 ' , 'betweenx', [750 4500] ); 



plotGraphData ( d at a . ss iz es . whee 1 . s N 2 , 'Planar Wheel Graph (Root 
Vertices > 500)', 'percentile', 100, 'percentilesteps', 100, 
'showbandsinlegend' , false , 'showdepthsbestfit' , false , 'save' , 
' Dif f erentSizes\Wheel-Small-N2-500 ' , 'betweenx', [500 4500] ); 



i/2Nth . 




plotGraphData ( d at a . ssi zes . whee 1 . s3 N4 , 'Planar Wheel Graph (Root = 3/4 
Nth, Vertices > 750)', 'percentile', 100, 'percentilesteps', 100, 
'showbandsinlegend' , false , 'showdepthsbestfit' , false , 'save' , 
' Dif f erentSizes\Wheel-Small-3N4-750 ' , 'betweenx', [750 4500] ); 



plotGraphData ( d at a . ssizes . wheel . s3 N 4a , 'Planar Wheel Graph (Root = 3 /4 
Nth, Vertices > 750, 2nd run)', 'percentile', 100, 'percentilesteps', 
100, 'showbandsinlegend' , false , 'showdepthsbestfit' , false , 'save' , 
' Dif f erentSizes\Wheel-Small-3N4a-750 ' , 'betweenx', [750 4500] ); 




plotGraphData ( d at a . s siz es . whe e 1 . s N , 'Planar Wheel Graph (Root 
Vertices > 750) ' , 'percentile ' , 100, 'percentilesteps ' , 100, 
'showbandsinlegend' , false , 'showdepthsbestfit' , false , 'save' 
' Dif f erentSizes\Wheel-Small-N-750 ' , 'betweenx', [750 4500] ); 



Nth . 



plotGraphData ( dat a . ssizes . random . s3N 4 , 'Random Face Trisection Graph 
(Root = 3/4Nth , Vertices > 400) ' , 'percentile' , 100, 'percentilesteps' . 
100, 'showbandsinlegend' , false , 'showdepthsbestfit' , false , 'save' , 
' Dif f erentSizes\Random-Small-3N4-400 ' , 'betweenx', [400 4500] ); 
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Figure 


A. 2. 5, 


1 


A. 2. 6, 




A. 2. 7, 


3 


A. 2. 8, 


4 


A. 2. 9, 


5 


A. 2. 21. 


6 
7 


A. 2. 22. 


8 


A. 2. 23, 


9 


A. 2. 24, 


10 


A. 2. 25, 


11 


A.2.30, 


12 
13 


A.2.31, 


14 


A.2.32, 




A.2.33, 




A.2.34, 




A.2.40, 




A.2.41, 


15 


A.2.42, 


16 


A.2.43 




and 




A.2.44 




A. 3.1, 


1 


A. 3. 2, 




A. 3. 3, 


3 


A. 3.4, 


4 


A. 3. 5, 


5 


A. 3. 6, 


6 
7 


A. 3. 7, 


8 


A. 3. 8, 


9 


A. 3. 9, 


10 


A. 3. 10, 


11 


A. 3. 11, 


12 
13 


A. 3. 12, 




A. 3. 13, 


15 


A.3.14, 


16 


A.3.15, 


17 


A.3.16, 


18 
19 


A.3.17, 




A.3.18, 




A.3.19, 




A.3.20, 




A.3.21 




and 




A.3.22 


20 




21 



Mat lab Code 



'Triangular Prism' ; 
'Random Face Trisection'; 
'Ordered Face Trisection 1 
' Planar Wheel ' ; 
' 1st ' ; 
' i/4 Nth ' 
' 1/2 Nth ' 
' 3/4Nth ' 
' Nth ' ; 



gnm. title. triangular 

gnm. title. random 

gnm. title. ordered 

gnm. title. wheel 

gnm. root. sO 

gnm.root.sN4 

gnm. root . sN2 

gnm. root. s3N4 

gnm. root .sN 

gn = fieldnames ( data. sizes ); 

for i = 1 : numel ( gn ) , 

rn = fieldnames( d a t a . s i z e s . ( gn{ i } ) ); 
for j =1: numel ( rn ) , 

plot GraphData ( data. sizes. (gn{i}).(rn{j}), [gnm. title. (gn{i}) 
Graph (Root = ' gnm. root. (rn{j}) ')'], 'percentile', 100, 
' per cent i lest eps ' , 100, ' showbandsinlegend ' , false , 
'showdepthsbestfit', true, 'save', ['DifferentSizesV upper ( 
gn{i}(l) ) lower ( gn{ i } (2 : numel (gn{ i }) ) ) '-Large-' 
rn{ j } (2 : numel( rn{ j }) ) ] ); 

end 

end 



Random Face Trisection ' : 
Ordered Face Trisection 1 
Triangular Prism' ; 
Planar Wheel ' ; 
14999 ' ; 



gnm. title. random 

gnm. title. ordered 

gnm. title. triangular 

gnm. title. wheel 

gnm. size, random 

gnm . size . or der ed = '14999'; 

gnm . s iz e . t r i angu 1 ar = '14999'; 

gnm . size . wheel = '15000'; 

gnm. root. sO = '1st'; 

gnm. root. sN4 = ' i/4Nth ' ; 

gnm.root.sN4a = ' 1/4 Nth , 2nd Run'; 

gnm. root. sN2 = ' i/2Nth ' ; 

gnm.root.s3N4 = '3/4Nth'; 

gnm. root. sN = 'Nth' ; 

gn = fieldnames ( data. edges ); 

for i = 1 : numel ( gn ) , 

rn = fieldnames ( d at a . e d ges . ( gn{ i } ) ); 
for j =l:numel ( rn ) , 

plotGraphData( data. edges. (gn{i}).(rn{j}), {'Execution Time of ', 
[ gnm . size .( gn{ i } ) ' Vertex ' gnm . t it le . (gn{ i } ) ' Graph (Root = ' 
gnm. root. (rn{j}) ')']}, 'percentile', 100, 'percentilesteps', 100, 
'showbandsinlegend' , false , 'showdepthsbestfit' , false , 
' usethresholdlimit ' , true, ' thresholdlimit ' , [0 300000000], 
'save', ['DifferentEdges \ Bi conne c t ed \ ' upper ( gn{i}(l) ) lower ( 
gn{ i } ( 2 : numel ( gn{ i } ) ) ) '-' rn{j}(2: numel ( rn{ j }) ) ] , 'betweenx', 
[30000 45000] ) ; 

end 

end 
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Figure Matlab Code 



screenSize = get (0,'ScreenSize 1 ); fig = figure( 'Position', [0 
screenSize(3) screenSize(4)] , ' PaperUni t s ' , 'inches' , 'PaperPosition' , 
[0 10 7], ' Color ' , ' white ' ) ; 

subplot (1 ,3 ,[1 2]), axis( [30000 40000 60000000 300000000] ), 
plotGraphData ( d at a . edge s . t r iangular . s N 4 , {'Execution Time of 14999 
Vertex', 'Triangular Prism Graph (Root = V4Nth)'}, 'percentile', 100, 
' per cent i lest eps ' , 100, 'showbandsinlegend' , false , ' showdepthsbestf it ' , 
false, 'betweenx', [30000 40000], 'newfigure', false ); 
subplot (1 ,3 ,3) , axis( [40000 45000 60000000 300000000] ), 
plotGraphData ( d at a . edge s . t r iangular . s N 4 , {'Execution Time of 14999 
Vertex', 'Triangular Prism Graph', '(Root = i/4Nth)'}, 'percentile', 100, 
' per cent i lest eps ' , 100, 'showbandsinlegend' , false , ' showdepthsbestf it ' , 
false , ' newf igur e ', false, 'save', 

' Dif f erentEdges\Biconnected\Triangular-N4-Split ' , 'betweenx' , [40000 
45000] ) ; 



screenSize = get (0, 'ScreenSize'); fig = figure( 'Position', [0 
screenSize(3) screenSize(4)] , ' PaperUni t s ' , 'inches' , 'PaperPosition' 
[0 10 7], ' Color ' , ' white ' ) ; 

subplot (1 ,3 ,[1 2]), axis( [30000 40000 60000000 300000000] ), 
plotGraphData ( d at a . edges . t r i ang ular . sN 4 a , {'Execution Time of 14999 
Vertex', 'Triangular Prism Graph (Root = i/4Nth , 2nd Run)'}, 
'percentile', 100, 'percentilesteps', 100, 'showbandsinlegend', false, 
'showdepthsbestfit', false, 'betweenx', [30000 40000], 'newfigure 1 , 
false ) ; 

subplot (1 ,3 ,3) , axis( [40000 45000 60000000 300000000] ), 
plotGraphData ( d at a . edges . t r i ang ular . sN 4 a , {'Execution Time of 14999 
Vertex', 'Triangular Prism Graph', '(Root = i/4Nth , 2nd Run)'}, 
'percentile' , 100, 'percentilesteps' , 100, 'showbandsinlegend' , false . 
'showdepthsbestfit', false, 'newfigure', false, 'save 1 , 
' Dif f erentEdges\Biconnected\Triangular-N4a-Split ' , 'betweenx' , [40000 
45000] ) ; 
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Figure Matlab Code 



screenSize = get (0 , 1 ScreenSize ' ) ; 
gnm. title. random = 'Random 

gnm. title, ordered 
gnm. title. triangular 
gnm. title. wheel 
gnm. size, random 
gnm. size. ordered 
gnm. size. triangular 
gnm. size. wheel 
gnm. root. sO 
gnm.root.sN4 
gnm.root.sN4a 
gnm.root.sN2 
gnm.root.s3N4 
gnm. root .sN 

gn = fieldnames( data. edges 
for i = 1 : numel ( gn ) , 

rn = fieldnames ( d at a . e dges . ( gn{ i } ) ); 
for j =1 : numel ( rn ) , 

d = dat a . ed ge s . ( gn{ i } ) . ( rn { j } ) . d at a . dep t hs 
dd = d(2: size(d.l) ,2) - d ( 1 : s ize ( d , 1 ) - 1 , 2 ) 



Face Trisection'; 
Ordered Face Trisection 1 
Triangular Prism ' ; 
Planar Wheel ' ; 
14999 ' 
14999 ' 

14999 ' 

15000 ' 
1st 1 ; 
lANth ' 
i/4Nth , 
1/2 Nth ' 
3/4Nth ' 
Nth ' ; 

); 



2nd Run' 



ddd = dd(2: size (dd,l) ,1) 
fig = figure( 'Position' , 
' PaperUnits ' , ' inches ' , ' 
' white ' ) ; 

tl = [ gnm . size .( gn{ i } ) ' 
t2 = [ ' Graph (Root = ' 
subplot (2 ,2 ,1) , hold all, 
a = axis; axis ( [30000 



- dd(l: size(dd.l) - 1 
[0 s cr eenS iz e ( 3 ) 
PaperPosition ' , [0 10 7] 



i) ; 

screenSize (4) ] 



Vertex ' gnm . t it le . (gn{ i }) ] : 
gnm. root. (rn{j }) ' Vertex) ' ] : 
plot( d(: , 6) , d(: , 4) , 'b' 
45000 a(3) a(4) ] ) ; 



' Color 1 



) 



xlabel( 'Number Of Edges' ); ylabel( 'Number of Conflicts' ); 
title ( { ' Segment Conflicts for Biconnected Sub-Graphs of ' . tl , 

t2 } ); 

subplot (2 ,2 ,2) , hold all, plot ( d(:, 6), d(:, 2), 'b' ); 
a = axis; axis ( [30000 45000 a(3) a(4)] ); 

xlabel ( 'Number Of Edges' ); ylabel( 'Mean Segment Depth' ); 
title( {'Mean Segment Depth for Biconnected Sub-Graphs of', tl . 

t2 } ); 

subplot (2 ,2 ,3) , hold all, plot( d ( 2 : size ( d , 1 ) , 6 ) , dd ); 

a = axis; if a(3) < -15, a(3) = -15; end; if a(4) > 20, a(4) = 
20; end; axis ( [30000 45000 a(3) a(4)[ ); 
title ( {'Change in Mean Segment Depth for Biconnected 
Sub-Graphs of ' , tl , t2 } ) ; 

xlabel ( 'Number Of Edges' ); ylabel( { 'Change in', 'Mean 
Segment Depth ' } ) ; 
subplot (2 ,2 ,4) , hold all, plot( d ( 3 : size ( d , 1 ) , 6 ) , ddd ); 

a = axis; if a(3) < -1, a(3) = -1; end; if a(4) > 1, a(4) = 1; 
end; axis ( [30000 45000 a(3) a(4)[ ); 

title ( {'Change in Change in Mean Segment Depth' , 'for 
Biconnected Sub-Graphs of ' , tl , t2 } ) ; 

xlabel ( 'Number Of Edges' ); ylabel( {'Change in Change in', 

'Mean Segment Depth'} ); 
print ( fig, '- dpng ' , [ ' Di f f er entEdge s \Bi conne ct ed \ ' upper ( 
gn{i}(l) ) lower ( gn{ i } ( 2 : numel ( gn{ i } ) ) ) '-' rn { j } ( 2 : numel ( rn { j } ) ) 
' - MSD ' ] , ' -rl50 ' ) ; 



end 



end 
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Figure Matlab Code 



plotGraphData ( data, edges . or dered . sN4 , {'Execution Time of ', '14999 
Vertex Ordered Face Trisection Graph (Root = i/4Nth) ' } , 'percentile', 
100, ' per cent i le s t eps ' , 100, ' showbandsinlegend ' , false , 
' showdepthsbestf it ' , false , ' save ' , 

' Dif f erentEdges\Biconnected\0rdered-N4-0_43000 ' , 'betweenx' , [30000 
43000] ) ; 
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Table 




Matlab Code 






6.3.2 


1 


n = fieldnames ( data. roots ) ; 




\ 




2 


for i=l:numel(n) , 








3 


r = fieldnames ( d at a . r oo t s . ( n{ 


}) ); 






4 


for j=l:numel(r) , 








5 


performKS2Tests ( data. roots 


(n{i}).(r{j}) ); 






6 


end 








7 


end 














J 
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E.4 Matlab Functions 



E.4.1 appendPercentiles.m 

function [dataout] = appendPercentiles ( datain , xcol , ycol , sortOrder ) 

% Appends a column to the data containing grouped percentile values relating to 
the y- column data grouped on the x- column data 

% 

% Usage : 

% dataout = appendPercentiles ( datain , xcol , ycol , [A . . . ] ) ; 

% 

% Will sort the data by the x-column then y-column and will extend the 
% matrix by one column that will contain percentiles. 

% The resulting matrix will be sorted (if sortOrder is not empty) as 
% specified in sortOrder variable (see the so r trows function for more 
% details) beore returning. 

sortedData = sortrows( datain, [xcol ycol] ); 
x =sortedData(:,xcol); 
numel = grpstats( x, x, 'numel' ); 

dataout = [sortedData ones ( size (x) )] ; 
i = 1; 

j = size(dataout ,2) ; 

for n = 1: size ( numel ) , 
for m=l:numel(n) , 

dataout (i , j ) = 100*m/ numel (n) ; 

i = i + 1; 

end ; 

end ; 

if ( ~isempty( sortOrder ) ) 

dataout = sortrows ( dataout , sortOrder ) ; 

end ; 



E.4.2 filldata.m 



function [d] = filldata(x, y) 

% Fill data 

ux = unique (x) ; 

if any( size (ux) ~= size(y)) , 
disp ( size (ux) ) ; 
disp( size(y) ); 

error ( ' MyToolbox : FILLDATA : IncorrectSize ' 

1 FILLDATA (X , Y) : unique(X) and Y must be the same dimensions') 

end ; 

n =size(x, 1); 

sorted = sortrows (x, 1); 
usorted = sortrows ( [ ux y] , 1) ; 
d = ones ( size (x) ) ; 

p = i; 

for k = l:n 

if sorted(k, 1 ) ~= usorted (p , 1), p = p + 1; end; 
d(k,l) = usorted(p,2) ; 

end ; 
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E.4.3 fitdata2.m 



12 


% 


1 ones ' 


1 


13 


% 


'x ' 


X 


14 


% 


'x2 ' 


xs 


15 


% 


'x3 1 


x§ 


16 


% 


'x4 ' 


x to the power 4 


17 


% 


' xlogx ' 


x.log (x) 


IS 


% 


' xloglogx ' 


x.log ( log (x) ) 


19 


% 


' xlnx ' 


x . In ( x ) 


20 


% 


' xlnlnx ' 


x.ln ( In (x) ) 


21 


% 


' logx ' 


log (x) 


22 


% 


' loglogx ' 


log ( log (x) ) 


23 


% 


1 lux ' 


ln(x) 


24 


% 


' lnlnx ' 


ln(ln(x)) 


25 


% 


' log2x ' 


log2(x) 


26 


% 


' loglog2x ' 


log2(log2(x)) 


27 


% 


Passing a nested 


cell array of v 



function [vargout] = fitdata2(x, y, whichfits 

%FITDATA2 Fit data to various expressions. 

% 

Usage : 

bestfit = fitdata2(X 



varargin ) 



Y, WHICHFITS, [ParamName, ParamValue , ...]) 



Where X and Y are Nxl matrices , respectively , containing the x and y 
data upon which a best fit is to be performed. WHICHFITS is a cell 
array that can contain character string names of best fits or a nested 
cell array containing best fit names. Valid names for best fits 
include : 



an expression formed of all the names and the best fit 
evaluated against this. 



'ill be 



ParamName and ParamValue are optional pairs of arguments that set 
additional options. These can include: 

' useRobustFit 1 boolean (default: true) 

The output is a struct with following fields : 

coefficients A struct containing one field for each best fit ; 

each field contains an array of coefficients for 
each term of the equation , starting with the 
constant term and then including all specified 
terms in order. 

cilower A struct containing one field for each best fit ; 

each field contains a [Mxl] array where M = 

s i z e ( unique (x ) ,1) containing data points for the 

lower bounds of the 95% confidence interval for the 

best fit corresponding to the values in unique(x). 

THIS IS OT FULLY TESTED AND MAY GIVE INCORRECT 

BOUNDS. 

ciupper A struct containing one field for each best fit ; 

each field contains a [Mxl] array where M = 

s i z e ( unique ( x ) ,1) containing data points for the 

upper bounds of the 95% confidence interval for the 

best fit corresponding to the values in unique(x). 

THIS IS OT FULLY TESTED AND MAY GIVE INCORRECT 

BOUNDS. 

data A struct containing one field for each best fit ; 

each field contains a [Mxl] array where M = 
s i z e ( unique ( x ) ,1) containing the best fit data 
points corresponding to the values in unique(x). 

equation A struct containing one field for each best fit ; 

each field contains a string representation of the 
equation of the best fit curve 

mae A struct containing one field for each best fit ; 
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each field contains the Mean Absolute Error (MAE) 
for the best fit. 
rmse A struct containing one field for each best fit ; 

each field contains the Root Mean Squared Error 
(RMSE) for the best fit. 

Example : 

x =(- 10:10) '; 

y = 2*x. ~3 - 38*x + 19; 

y(21) = 0; 

bf = fitdata2 ( x, y , { 'x3 ' , 'x2 ' , 'x' , { 'x3 ' , ' x2 '} , ... 

{ 'x3', 'x2', 'x' } }, ' userobustfit ' , true ); 
figure ; hold all; 

plot( x, y, ' + ', 'MarkerSize', 3, ' DisplayName ' , 1 Data 1 ) ; 
fn = f ieldnames ( bf . d at a ) ; 
for f = 1 : numel ( fn ) , 

plot( unique(x), bf.data.(fn{f}), ... 
'DisplayName', b f . e qu at io n . ( fn { f } ) ); 

end ; 

legend ( 'show' , 'Location ' , 'best ' ) ; 

bf.rmse 

bf.mae 

Change 'userobustfit ' option to false to see the difference in fit. The 
difference between the robustness of the metrics is also apparent as RMSE 
shows that the optimal fit is the y=ax§+bxs+c curve whereas MAE correctly 
identifies the y=axs+bxs+cx+d curve as the optimal fit. 



i f nargin < 3 , 

error ( 1 MyToolbox : FITDATA2 : TooFew Inputs ' , . . 
' FITDATA2 requires three arguments. ') 



end ; 



i f any ( size(x) ~= size(y) ), 

error ( 1 MyToolbox : FITDATA2 ' , . . . 

' FITDATA2 x and y must be the same dimensions') 

end ; 

102 if isempty ( wh i chf it s ) , 

103 fitnames = { 'x' , ' xlogx ' , 'xloglogx' }; 

104 else 

105 fitnames = checkfitname ( whichfits , true); 

106 end 



1112 
113 

115 
116 
117 
US 
119 
120 
121 
122 
123 
12-1 
125 
120 
127 



options = struct ( 'userobustfit 1 , true ) ; 

options = processOptions ( options , ' Graphs : PL0TGRAPHD ATA ' , varargin ) 

n = size (x , 1) ; 
ux = unique ( x ) ; 

for k = l:numel ( fitnames ) 
names = fitnames{k}; 
if is c h ar ( names ) , 
name = names ; 

else 

name = names { 1 } ; 

if numel (names) > 1, 

for 1 =2: numel ( names ) 

name = strcat (name , ' _ ' , names { 1 }) ; 

end ; 

end ; 

end ; 

d = [ ones ( size (x) ) generatedata (x , fit names {k })] ; 
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ud = [ ones ( size ( ux) ) generatedata (ux , fit names {k} )] ; 

if o p t i ons . user o b us t f i t , 

[vargout. coefficients. ( name ),s] = robustfit( d(:,2:size(d,2)), y ); 
ci = . . . 

nlparci ( vargout. coefficients, (name) ,s.resid , 1 cov ' ,s.covb); 



else 



vargout. rmse. ( name ) 
vargout. mae. (name) 
clear s ; 

[vargout. coefficients. ( name ) 



= sqrt (sum( s.resid. ~2)/n) 
= sum( abs (s.resid)) /n ; 



ci, residuals] ... 
= regress (y , d) ; 
= sqrt (sum( r e s id u al s . ~ 2) /n) ; 
= sum(abs ( residuals )) /n ; 



vargout . rmse . (name) 
vargout. mae. (name) 
clear residuals ; 

end ; 

vargout. cilower. ( name ) 
vargout. ciupper. ( name ) 
clear ci ; 

var gout . d at a . (name) 
coefficients = vargout 
coef = regexp ( name, '_ 
text = [] ; 

for c =2: numel ( c o e f f i c i e n t s ) , 
if isempty( text ) , 

text = num2str ( c o e f f i c i e n t s ( 2 ) ) ; 

else 

text = strcat ( text, formatNumber ( c o e f f i c i e n t s ( c ) ) ) 



= ud* ci ( : , 1 ) ; 
= ud* c i ( : , 2 ) ; 

= ud* v a r go u t . c o e f f i c i e n t s . (name) ; 
coefficients. ( name ) ; 
, ' split ' ) ; 



156 


end ; 












157 


switch 


char ( coe 


f(c-l) ) 








158 


case ' 


x 1 , 


text = 


strcat ( 


text , 


'x' ); 


159 


case 1 


x2 ' , 


text = 


strcat ( 


text , 


' x~2 ' ) ; 


160 


case ' 


x3 1 , 


text = 


strcat ( 


text , 


' x~3 ' ) ; 


161 


case ' 


x4 ' , 


text = 


strcat ( 


text , 


' x-4 ' ) ; 


102 


case ' 


lnx ' , 


text = 


strcat ( 


text , 


'ln(x)' ); 


163 


case ' 


lnlnx ' , 


text = 


strcat ( 


text , 


'ln(ln(x))' ); 


164 


case 1 


xlnx 1 , 


text = 


strcat ( 


text , 


' x{\cdot}ln (x) ' ) ; 


165 


case ' 


xlnlnx 1 , 


text = 


strcat ( 


text , 


■x{\cdot}ln(ln(x)) 1 ) 


166 


case ' 


logx ' , 


text = 


strcat ( 


text , 


'log(x)' ); 


167 


case ' 


loglogx 1 , 


text = 


strcat ( 


text , 


' log (log (x)) ' ); 


168 


case ' 


log2x ' , 


text = 


strcat ( 


text , 


' log_2(x) ' ) ; 


169 


case 1 


loglog2x 1 , 


text = 


strcat ( 


text , 


' log_2 (log_2 (x) ) 1 ); 


170 


case ' 


xlogx ' , 


text = 


strcat ( 


text , 


■x{\cdot}log(x) ' ) ; 


171 


case ' 


xloglogx ' , 


text = 


strcat ( 


text , 


' x{\cdot}log (log (x) ) ' 


172 


end ; 













end ; 

v ar gout . equat ion . (name) = strcat ( 1 y= 

); 



text , formatNumber ( coefficients (1) ) 



end 



function [data] = generatedata (x , 

7GENERATEDATA Generates fit data, 
if ischar( name ) , 



name ) 



180 


switch name 






181 


case 


1 ones ' , 


data = 


[]; 


1S2 


case 


' x 1 , 


data = 


x ; 


183 


case 


' x2 ' , 


data = 


x. '2; 


184 


case 


' x3 ' , 


data = 


x. '3; 


185 


case 


' x4 ' , 


data = 


x. ~4; 


186 


case 


1 lnx ' , 


data = 


log(x) ; 


187 


case 


1 lnlnx ' , 


data = 


log(log(x) ) ; 


188 


case 


1 xlnx 1 , 


data = 


x. *log (x) ; 


ISO 


case 


' xlnlnx ' , 


data = 


x.*log(log(x) ) ; 


190 


case 




data = 


loglO(x) ; 


191 


case 


1 loglogx 1 , 


data = 


Iogl0(logl0(x)) 
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case 
case 
case 
case 



' log2x 1 , 
' loglog2x ' 
1 xlogx 1 , 
1 xloglogx 1 



otherwise . 



end 



else 



data = log2 ( x ) ; 

data = log2 (log2 (x) ) ; 

data = x.*loglO(x) ; 

data = x . * loglO ( loglO (x) ) 

data = [ 1 ; 



data = [ ] ; 

for j = 1 : numel ( name ) 

data = [data generatedata (x , 

end 



end ; 



end 



name{ j }) ] ; 



function [ f n ] = checkfitname (name , propogate) 

%CHECKFTTNAME Checks to see if the name of the fit 
i f nargin = 1 , 

propogate = true ; 

end 



is valid. 



if iscellstr( name ) , 
fn = {}; 

for j = 1 : numel (name) 

fit = checkfitname (name{j } , false); 
if ~isempty( fit ) , 

fn {numel (fn) + 1} = fit ; 

end ; 

end ; 

elseif i s c e 1 1 ( name ) , 
i f propogate , 
fn = {}; 

for j = 1 : numel ( name ) 

fit = checkfitname (name{ j } , false) 
if ~isempty( fit ) , 

fn{numel(fn) + 1} = fit ; 

end ; 

end ; 

else 

fn = []; 

end ; 

elseif ischar( name ) , 
switch name 

case { ' ones ' , 
' lnlnx ' , 1 xlogx 
} 

fn = name; 
otherwise 

warning ( 1 MyToolbox : FITDATA2 ' , 1 Ignoring unknown fit: °/,s',name) 

fn = []; 

end ; 

else 

fn = []; 

end ; 
end 



, ' x2 ' , ' x3 1 , ' x4 1 
' xloglogx ' , ' logx ' 



xlnx ' , 1 xlnlnx ' , 1 lnx ' , 
loglogx ' , ' log2x ' , 'loglog2x ! 



function [str] = formatNumber ( n ) 
if n < 0, 

str = num2str(n) ; 

else 

str = [' + ' num2str(n) ] ; 

end ; 

end 



end 
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E.4.4 fitdatatoarray.m 



function [vargout] = f i t da t at o ar r ay (x , y, ya , varargin) 

% Fit data to an array. 

% 

Usage : 

bestfit = f i t d at at o ar r ay ( X, Y, YA, [ParamName, ParamValue , ••■] ); 



Where X and Y are Nxl matrices and YA is a Mxl matrix 
number of unique elements in X. 



/here M is the 



ParamName and ParamValue are optional pairs of arguments that set 
additional options. These can include: 

' useRobustFit ' boolean (default: true) 

The output is a struct with following fields : 



coefficients 



cilo wer 



ciupper 



data 



equation 



Example : 
xl 



(- 10:10) 
[xl; xl; 



A struct containing one field for each best fit ; 
each field contains an array of coefficients for 
each term of the equation , starting with the 
constant term and then including all specified 
terms in order. 

A struct containing one field for each best fit ; 

each field contains a [Mxl] array where M = 

s i z e ( unique ( x ) ,1) containing data points for the 

lower bounds of the 95% confidence interval for the 

best fit corresponding to the values in unique(x). 

THIS IS OT FULLY TESTED AND MAY GIVE INCORRECT 

BOUNDS. 

A struct containing one field for each best fit ; 

each field contains a [Mxl] array where M = 

s i z e ( unique ( x ) ,1) containing data points for the 

upper bounds of the 95% confidence interval for the 

best fit corresponding to the values in unique(x). 

THIS IS OT FULLY TESTED AND MAY GIVE INCORRECT 

BOUNDS. 

A struct containing one field for each best fit ; 
each field contains a [Mxl] array where M = 
size ( unique (x) ,1) containing the best fit data 
points corresponding to the values in unique(x). 
A struct containing one field for each best fit ; 
each field contains a string representation of the 
equation of the best fit curve 

A struct containing one field for each best fit ; 
each field contains the Mean Absolute Error (MAE) 
for the best fit. 

A struct containing one field for each best fit ; 
each field contains the Root Mean Squared Error 
(RMSE) for the best fit. 



xl 



y = 0.01*x.~3-x + 23 + . 4 *randn ( 63 , 1 ) 
ya = s in ( - pi : pi / 1 : pi ) '; 
bf = f i t d a t a t o ar r ay ( x, y, ya , 
figure ; hold ; 

plot ( x, y, 'b+', ' DisplayName ' 
bf . data , ' r- ' 



' userobustfit 1 , true ) 



plot ( unique (x) 
legend ( ' Show ' , 
bf.rmse 
bf.mae 



'Data ' , ' MarkerSize ' , 3 ) ; 
'DisplayName', bf. equation) 



'Location ' , 'Best ' ) 



if any( size ( x ) ~= size ( y ) ) 
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error ( 1 MyToolbox : FITDATATOARRAY ' , . . . 

' FITDATATOARRAY x and y must be the same dimensions') 

end ; 

ux = unique ( x ) ; 

if any( size (ux) ~= size (ya) ) , 

error ( 1 MyToolbox : FITDATATOARRAY : IncorrectSize ' , . . . 

' FITDATATOARRAY (X , Y , YA) : unique(X) and YA must be the same dimensions') 

end ; 

options = struct( 'userobustfit', true, ... 

' terms 1 , {{}}); 

options = processOptions ( options, ' Graphs : PLOTGRAPHD ATA ' , varargin ); 



terms = options . terms ; 
for k = l:numel ( terms ) , 

switch lower( terms{k} ) , 
82 case { 1 x ' , ' lnx ' , 1 lnlnx 1 

S3 otherwise, terms (k) = []: 

end ; 

end ; 



' x2 1 



1 x3 ' 



1 x4 1 



' xlnx ' , 1 xlnlnx ' } , 



n =size(x, 1); 

sorted = sortrows ([x y] , 1) ; 

usorted = sortrows ( [ ux ya] , 1) ; 

d = [ones( size (x) ) zeros( size(x, 1), 2* numel (terms) + 1 )]; 

ud = [ones(size (ux) ) ya zeros( size( ux , 1 ) , 2* numel (terms ) ) ] ; 

p =1; 

for k = l:n 

if sorted(k, 1 ) ~= u s o r t e d ( p , 1), p = p + 1; end ; 
d(k,2) = usorted(p,2) ; 

end ; 



98 
99 
100 
101 
102 
103 
10-1 
105 
106 
107 
10S 
109 
110 

111 

112 
113 
111 
115 
116 
117 
US 
119 
120 
121 
122 
123 

124 
125 
126 



for k = l:numel ( terms ) , 

switch lower( terms{k} ) 
case 1 x ' , 



d(: , 


l+((k*2) : (k*2+ 


1)) 




= d(: , 


1 


2) . *[x x] ; 


ud(: 


, ((k*2 + l) : (k*2 


+2) 


) 


) = ud( 




1:2) . * [ ux ux ] ; 


case ' lnx ' , 












d(: , 


l + ((k*2) : (k*2+ 


1)) 




= d(: , 


1 


2) . *[log(x) log(x) ] ; 


ud(: 


, l + ((k*2) : (k*2 


+ 1, 


) 


) = ud( 




1:2) . *[log(ux) log(ux) ] ; 


case ' lnlnx 1 , 












d(: , 


l + ((k*2) : (k*2 + 


1)) 




= d(: , 


1 


2) .*log(log(x)) ; 


ud(: 


, l+((k*2) : (k*2 


+ ly 


) 


) = ud( 




1:2) . *[log(log(ux) ) log(log(ux)) ] ; 


case ' x2 














d(: , 


l + ((k*2) : ( k*2 + 


1)) 




= d(: , 


1 


2) . *(x. ~2) ; 


ud(: 


, l+((k*2) : (k*2 


+ ly 


) 


) = ud( 




1:2) . *[ux.~2 ux. ~2]; 


case 1 x3 


1 












d(: , 


l+((k*2) : ( k*2+ 


1)) 




= d(: , 


1 


2) . *(x. ~3) ; 


ud(: 


, l + ((k*2) : (k*2 


+i; 


) 


) = ud( 




1 : 2) . * [ ux. "3 ux. " 3] ; 


case ' x4 














d(: , 


l + ((k*2) : (k*2 + 


i)) 




= d(: , 


1 


2) . *(x. -4) ; 


ud(: 


, l + ((k*2) : (k*2 


+i) 


) 


) = ud( 




1 : 2 ) . * [ ux. ~4 ux. ■*■ 4] ; 


case ' xlnx ' , 












d(: , 


l + ((k*2) : (k*2 + 


i)) 




= d(: , 


1 


2 ) . * ( x . * log (x ) ) ; 


ud(: 


, l+((k*2) : (k*2 


+ ly 


) 


) = ud( 




1 : 2 ) . * [ ux . * log ( ux ) ux. *log (ux) ] ; 


case 1 xlnlnx 1 , 












d(: , 


l + ((k*2) : (k*2 + 


1)) 




= d(: , 


1 


2) . *(x.*log(log(x) )) ; 


ud(: 


, l+((k*2) : (k*2 




) 


) = ud( 




1:2) . *[ux.*log(log( ux ) ) 


ux . * 


log ( log (ux) ) ] ; 













end ; 

end ; 

if o p t io ns . user obus t f i t , 
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127 


[ vargout. coefficients 


s] = robustfit( d ( : , 2 : size (d , 2 ) ) , 


128 


c i 


= n lp ar c i ( v ar g o u t . c o e f f i c i e n t s 


129 




' cov ' , s . co vb ) ; 


130 


vargout. is Robust Fit 


= true ; 


131 


vargout .rmse 


= sqrt (sum( s . r e s i d . " 2) /n) ; 


132 


vargout. mae 


= sum ( abs (s.resid))/n; 


133 


clear s ; 




134 


else 




135 


[ vargout. coefficients 


ci, residuals] = regress ( sorted ( 


136 


var gout. isRobust Fit 


= false; 


137 


vargout .rmse 


= sqrt (sum( residuals. "2)/n) ; 


138 


vargout. mae 


= sum(abs( residuals ) )/n; 


139 


clear residuals ; 




140 


end ; 





d); 



vargout. cilower 
vargout. ciupper 
clear ci d; 
vargout . data 
var gout. equation 



ud* c i ( : , 1 ) ; 
ud* c i ( : , 2 ) ; 

ud* v ar g o u t . c o e f f i c i e n t s ; 

[ ' y= ' num2str ( v ar go u t . c o ef f i c i e n t s ( 2 ) ) 'f(x) 
for mat Number ( vargout. coefficients (1) ) ] ; 



for k = l:numel ( terms ) , 

switch lower( termsjk} ) 



151 


case 


1 x 1 , 


eqn = 


x 1 ; 


152 


case 


' lnx ' , 


eqn = 


ln(x) ' ; 


153 


case 


' lnlnx ' 


eqn = 


ln(ln(x)) ' ; 


154 


case 


1 x2 ' , 


eqn = 


x-2 ' ; 


155 


case 


1 x3 ' , 


eqn = 


x-3 ' ; 


156 


case 


' x4 ' , 


eqn = 


x-4 ' ; 


157 


case 


' xlnx ' , 


eqn = 


x{\cdot}ln(x) ' ; 


158 


case 


1 xlnlnx 


, eqn = 


x{\cdot}ln(ln(x) ) 


159 


end ; 








160 


vargout . 


equation 


= strcat( 


vargout . equation , 



for mat Number ( vargout 
for mat Number ( vargout 



coefficients (2* k+2) ) 
coefficients (2*k+l)) 



' + 1 eqn 
f(x)' 

')■) ); 



{\cdot}( ' 



end ; 



function [str] = formatNumber ( n ) 
if n < 0, 

str = num2str(n) ; 

else 

str = [' + ' num2str(n) ] ; 

end ; 

end 



end 
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E.4.5 loadAndSplitGraphData.m 



function [data] = loadAndSplitGraphData ( data, path, inputID , type, ... 
splitOn , splitlDs , outputlDs ) 

93X)ADANDSPLITGRAPHDATA Loads Graph Data and separates out errors and 
%garbage collections. 

% 

% Usage : 

% [data] = loadGraphData( P, ID, T ); 

% 

% Where: P is a character array in the format: '<File Directory >\<File 
% Stub>'; ID is a cell array containing character strings; and T is one 
% of 'vertex ' , 'edge ' , 'root ' . 

% 

% Example : 

% [data] = loadGraphData( ' Data\ SameRootsGraph - ' , { '50', '100' }, 

% 'root' ); 

% 

% Will try to load and process the files : 

% 'Data\SameRootsGraph-50_Total.log '; 

% 'Data\SameRootsGraph-50_Depths.log '; 

% 'Data\SameRootsGraph-100_Total.log'; and 

% ' Data\SameRootsGraph- 100 _Depths.log 1 

% 

% The Totals log file should have the following columns: 

% 1) Number of Vertices; 

% 2) Number of Edges; 

% 3) Root Vertex ID; 

% 4) Execution Time (ns) ; and 

% 5) Number of Garbage Collections; 

% 

% The following columns are added to the data: 
% 6) Sequentially incremented row index; and 

% 7) Grouped Percentile for data (grouped using the 'type' column). 

% 

% The Depths log file should have the following columns: 

% 1) Number of vertices /edges or root vertex id for the given 'type' 

% argument. 

% 2) The average segment depth of the graph. 

% 

% The output is a struct containing one child element for each element in 
% the ID cell array (in the format ]'s' ID{k}]). Each child has the 
% following children : 

% type Set to the type argument. 

% data. error Contains rows from the total log file where the 

% execution time is negative. 

% data.gc Contains rows from the total log file where the 

% number of garbage collections is non-zero and 

% the execution time is positive. 

% data.gc Contains rows from the total log file where the 

% number of garbage collections is zero and the 

% execution time is positive. 

% data. depths Contains the rows from the depths log file. 

% 

switch lower ( type ) , 

case 'vertex' , xcol = 1; 
case ' edge ' , xcol = 2; 

case 'root', xcol = 3; 

otherwise, xcol = 1; 

type = 'vertex'; 

end ; 

switch lower ( splitOn ) , 
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63 




case 'vertex' , scol 


= 1; 




64 




case ' edge ' , scol 


= 2; 




65 




case ' root ' , scol 


= 3; 




66 




otherwise , scol 


= 1; 




67 


end ; 








69 


n 






load( [path inputID '_Total.log'] ); 


70 


for 


i = 1 : numel (splitlDs) , 






71 




depthFile 




[path outputIDs{i} '_Depths.log']; 


72 




name 




[ 's ' outputIDs{i }] ; 


73 




data, (name) .type 




type; 


74 




[o n] 




removeoutliers ( n, scol , 4, 'notequaltox 


75 








splitIDs{i}) ; 


76 




[correct data.( name ) 


data 


error ] ... 


77 








removeoutliers ( [o (l:size(o,l)) '] , ... 


78 








xcol ,4, ' lessthany ' , ) ; 


79 




clear o; 






80 




[data. (name) . dat a . no£ 


;c dat a . ( name ) . d at a . gc ] = removeoutliers ( ... 


81 








appendPercentiles ( correct , xcol , 4, 6 


82 








xcol , 5 , ' greaterthany 1 , ) ; 


83 




clear correct ; 






84 




dat a . (name) . dat a . dep t hs = 


load ( depthFile ) ; 


85 


end ; 









E.4.6 loadGraphData.m 



function [data] = loadGraphData ( data, path, ids , type, varargin ) 

%LOADGRAPHDATA Loads Graph Data and separates out errors and garbage 
%collections. 

% 

Usage : 

[data] = loadGraphData( P, ID, T ); 



Where: P i: 
Stub>'; ID 
of ' vertex 

Example : 

[ data | 



a character array in the format: '<File Directory >\<File 
is a cell array containing character strings; and T is one 



1 edge ' 



root 



= loadGraphData ( 
' root ' ) ; 



' Data\ SameRootsGraph - 



{ '50', '100' }, 



Will try to load and process 
' Dat a \ SameRootsGraph - 
' Data\ SameRootsGraph - 
' Data\ SameRootsGraph - 
' Dat a \ SameRootsGraph - 



the files : 
50 _Total.log 1 : 
50 _ Depths, log 
100_Total.log 1 ; 
100_Depths.log 



The Totals log file should have the following columns: 

1) Number of Vertices; 

2) Number of Edges ; 

3) Root Vertex ID; 

4) Execution Time (ns) ; and 

5) Number of Garbage Collections ; 

The following columns are added to the data: 

6) Sequentially incremented row index; and 

7) Grouped Percentile for data (grouped using the 'type' column). 

The Depths log file should have the following columns: 

1) Number of ve r t i ce s / edges or root vertex id for the given 'type 

argument . 

2) The average segment depth of the graph. 
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% 
% 
% 
% 
% 
% 
% 
% 
% 
% 
% 
% 
% 
% 



The output is a struct containing one child element for each element in 
the ID cell array (in the format [ ' s ' ID {k } ] ) . Each child has the 
following children : 

type Set to the type argument, 

data. error Contains rows from the total 

execution time is negative, 
data.gc Contains rows from the total log 

number of garbage collections is 
the execution time is positive, 
data.gc Contains rows from the total log 

number of garbage collections is 
execution time is positive, 
data. depths Contains the rows from the depths log file 



log file where the 



file where the 
non- zero and 

file where the 
zero and the 



options = struct( 'filepostfix', 'Total' ); 

options = processOptions ( options , ' Graphs : PLOTGRAPHD ATA ' , varargin ) 



switch lower ( type ) 



case 
case 
case 'root 
otherwise , 



vertex ' 
edge ' , 



end ; 



xcol = 1 



xcol = 2 

xcol = 3 

xcol = 1 
type 



= 'vertex' 



for i =l:numel ( ids ) , 

totalFile = [ path ids{i} '_' options. filepostfix '.log']; 
depthFile = [path ids{i} '_Depths.log']; 
if ( ~exist ( totalFile , 'file' ) ) 

disp( [totalFile ' does not exist.'] ); 

continue ; 

end ; 

if ( ~exist ( depthFile, 'file' ) ) 

disp( [depthFile ' does not exist.'] ); 
continue ; 

end ; 

name = ]'s' ids{i}[; 

data, (name) .type = type; 

o = load ( totalFile ); 

[correct dat a. ( name ) . d a t a . e r r o r ] ... 

= removeoutliers( [o (l:size(o,l)) '] , 
xcol , 4 , ' 1 e s sthany ' , ) ; 

clear o; 

[ dat a. ( name) . dat a . nogc dat a . (name ) . d at a . g c ] = removeoutliers ( 

appendPercentiles ( correct , xcol , 
xcol , 5, ' greaterthany ' , ) ; 

clear correct ; 

d at a . (name) . d at a . dep t hs = load ( depthFile ); 

end ; 



6 ) 
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E.4.7 performKS2Tests.m 

< 

function [s] = performKS2Tests ( data, varargin ) 

options = struct ( 'percentile 1 , 100, ... 

1 mapx 1 , false ,.. . 

'betweenx', [-1-1], ... 

1 xlimit ' , - 1 . . . 

); 

options = processOptions( options, ' Graphs :PLOTGRAPHDATA', varargin ); 

switch (data. type) 

case 'vertex' , xcol = 1; 
case ' edge ' , xcol = 2; 

case 'root', xcol = 3; 

otherwise, warning( ' Graphs : PLOTNUMBEROFELEMENTS ' , ... 

'Unknown Data Type: Assuming vertex' ); 

xcol = 1 ; 

end ; 

s . xcol = xcol ; 

d= [data. data, nogc (: , xcol) data. data. nogc(:, 4) data. data. nogc(:, 7)]; 

g= [data. data. gc(:, xcol) data. data. gc(:, 4) data. data. gc(:, 7)]; 

if options. percentile <= , 
return ; 

end ; 

s . c ou n t . n o gc . bef o r e = size(d,l) ; 
s . c o un t . g c . b e f o r e = size(g,l); 
if o p t i o n s . p e r c e n t i 1 e < 100, 

d=removeoutliers(d, 2, 3, 'greaterthany', options. percentile ); 
g=removeoutliers( g, 2, 3, 'greaterthany', options. percentile ); 

33 s. percentile = o p t i o ns . p e r c e n t i le ; 

34 else 

s. percentile = 100; 

end ; 

37 s . c o un t . n o gc . af t er = size(d,l) ; 

38 s . c o u n t . g c . af t e r = size(g,l); 

i f any (options, betweenx ~=[-l -1[), 

d = removeoutliers( d, 1, 2, 'notbetweenx' , options. betweenx ) ; 
g = removeoutliers( g, 1, 2, 'notbetweenx' , options. betweenx ) ; 

end ; 

45 if options. mapx && xcol = 3, 

46 fnct = inline ( 'round(mod(x,3)*y/3)+ceil(x/3)' ); 
d = sortrows ( [ f nc t ( d(:,l), max( d(:,l)) ) d(:, 2) zeros(size(d,l),l); 

fnct( g(: ,1) , max(g(: ,1)) ) g(: , 2) 
ones ( size (g , 1) , 1 ) ] ); 

else 

d = sortrows( [d(:,l) d(:,2) zeros ( size ( d , 1 ), 1 ) ; g(:,l) g(:,2) 

ones ( size (g , 1 ) ,1)] ); 

end ; 

x = d(: , 1) ; 
y = d(: , 2) ; 
ux = unique ( x ) ; 

n = grpstats( y, x, 'numel' ); 

if op t i ons . xl imi t > 0, 
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else 



maxi = min( options. xlimit , numel(n) ) 
maxi = numel(n) ; 



end ; 



s . x 

s . nogc 
s.gc 



= ux ( 1 : maxi . 
= c e 1 1 ( maxi . 
= c e 1 1 ( maxi . 



1 ) 
1 ) 
1 ) 



p = 0; 

for i = l:maxi , 
dd 

[gc nogc] 

if numel(nogc) > 0, 
s .nogc { i } 
s. mean. nogc ( i ) 
s.sd.nogc(i) 

end ; 

i f numel ( gc ) > , 
s.gc{i} 
s.mean.gc ( i ) 
s.sd.gc (i) 
if numel (nogc) 
s . ks ( i ) 
s.cm ( i ) 
% s . k ( i ) 

% full 
% groups 
% s.kw(i) 
% s . an ( i ) 



d( p + (l:n(i)) ' , : ) ; 
removeoutliers( dd , 1 

nogc ( : , 2 ) ; 
mean (s.nogc{i}); 
std(s.nogc{i}) ; 



gc(:, 2); 
mean ( s . g c { i } ) 
std ( s.gc { i }) ; 



' equalt oy ' , 1 ) ; 



> 0, 



= kstest2( s.nogcji}, s.gc{i} ); 
= cmtest2( s.nogc{i}, s.gc{i} ); 

= kuipertest2( s.nogc{i}, s.gcji} ); 
= [ s.nogc { i }; s.gc{i }] ; 

= [ ones ( s i z e ( s . nogc { i })) ; zeros ( size ( s.gc{ i }) ) ] 
= kruskal wallis ( full , groups , ' off ' ) ; 
= anoval ( full , groups , 1 off ' ) ; 



end ; 



end ; 

P 



P + n( i ) ; 



end ; 
if i 



% 

else 



sfield ( s , 'ks ' ) , 
fprintf ( 1 \t&\n ' ) ; 

fprintf( ' \ t °/,d &\n ' , numel ( s . x ) ) ; 

fprintf( ' \ty.d C/.3 . 3f W/.'/O &\n', sum(s.ks), ( 100*sum( s . ks ) /numel ( s . ks ) ) ) 
fprintf( 'Xt'/.d C/.3 . 3f W/.7.) \n ' , sum(s.cm), ( 1 00*sum( s.cm ) /numel ( s.cm ) ) ); 

fprintf ( '\t%d (%3 . 3 f \\%%)\n ' , sum(s.k), ( 1 00* sum ( s . k ) /numel ( s . k ) ) ); 
fprintf( ' \\ t abularnewl ine \n 1 ); 



disp( [ 'No data: No GC = ' num2str( s . count . nogc . after ) '/' 
num2str ( s . c o unt . no gc . b ef or e ) 1 (' ... 
num2str (100* s. count. nogc. after / s. count. nogc. before ) 
'"/,), GC = ' num2str ( s . c o u n t . gc . af t e r ) '/' ... 
num2str( s . count . gc . before ) ' (' ... 

num2str (100* s. count, gc. after / s. count, gc. before) ' V/, ) ' ] ) 



end ; 
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E.4.8 plotGraphData.m 



function plotGraphData ( data, titleText , varargin ) 
options = struct ( 



' type ' , 

' percent ile ' , 

1 per cent i lest eps ' , 

1 lowcolour ' , 

' highcolour ' , 

' newf igur e ' , 

1 mapx 1 , 

' plot segment s 1 , 

' us ehs 1 ' , 

'flipdepths' , 

' showbestf its', 

' showdepthsbestf it 1 , 

' shows egment sbe st f it 

' showdept hsumbe st f it 

' showbestf itrmse ' , 

' showbestf itmae ' , 

' showbe st f i t c i s ' , 

'bestfits' , 

' user obustf it ' , 

' showbandsinlegend ' , 

1 save ' , 

1 betweenx ' , 

' thresholdlimit 1 , 

' showthresholdlimit 1 

' usethresholdlimit 1 , 

' scalethreshold ' , 



' nogc 1 , ... 
90, ... 
30, ... 
[0 0], ... 
[ .7 .7 .7] , 
true , 
false , 
false , 
false , 
false , 
true , 
true , 
false , 
false , 
false , 
true , 
false , 

{{ , 
true , 
true , 

[-1 -1] 
[0 0], 
false , 
false , 

o ); 



xlnx ' , 1 xlnlnx ' } } . 



options = processOptions( options, 'Graphs: PLOTGRAPHDATA', varargin ); 

op t io ns . p e r c en t i le = min( max( o pt io n s . per cent i le , ) , 100 ) ; 

if op t i o n s . p e r c e n t i 1 e = 0, 

warning ( ' Graphs : PLOTGRAPHDATA ' , ... 

'Percentile is zero; no data to plot. ' ) 
return ; 

end ; 

switch lower ( options, type ) , 



case ' nogc 
case ' gc ' , 
case ' full 
otherwise , 



d = dat a . dat a . nogc ; 
d = data. data. gc ; 

d = [ dat a. dat a. nogc ; data. data. gc 
warning( ' Graphs : PLOTGRAPHDATA ' , 

'Invalid type, assuming "nogc' 

d = dat a . dat a . nogc ; 



end ; 



if 



opt io ns . newf igur e , 
screenSize = get (0 , ' ScreenSize ' ) ; 

% figure( 'Position', [screenSize(3)/6 screenSize(4)/6 2*screenSize(3)/3 
2*screenSize (4) /3] , ' PaperSize ' , [20.98 29.68], 'Color', 'white'); 

fig = figure ( 'Position' , [0 sc r een S ize ( 3 ) screenSize (4) ] , 'PaperUnits 
'inches', ' PaperPos i t i on ' , [0 10 7], 'Color', 'white'); 

else 

fig = gcf; 

end ; 



58 


case 


'vertex' , 


xcol = 


1; 


59 


case 


' edge ' , 


xcol = 


2; 


60 


case 


' r oot ' , 


xcol = 


3; 
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otherwise, warning( ' Graphs : PLOTGRAPHD ATA ' , 'Unknown Data Type: 

Assuming vertex' ); 

xcol = 1 ; 

end ; 

depths = dat a . data. depths ; 

if size ( depths , 2 ) < 3, 

if op t ions . plot segment s , 

disp( ' plot segment s = false' ); 

op t ions . plot segment s = false; 

end 

if op t ions . sho wsegment sbes t f i t , 

disp( ' shows egment sbe st f i t = false' ); 
op t ions . sho wsegment sbes t fit = false; 

75 end 

76 if options. showdepthsumbestfit , 
disp( 'showdepthsumbestfit = false' ); 
opt ions . sho wdepthsumbest fit = false; 

79 end 
so end 

if opt ions . plot segment s , 

83 d= [d filldata(d(:,xcol), depths (:, 3 ))] ; 

84 xcol = size(d,2); 
end 

87 if options. mapx && xcol = 3, 

88 fnct = inline ( ' ceil ( (mod (x , 3) *y + x) /3) ' ); 
else 

fnct = [] ; 

end ; 

if ~isempty( titleText ) , 

if o p t i o n s . p e r c e n t i le < 100, 

95 t = [ num2str ( op t i o ns . p er c e n t i 1 e ) ' th Percentile']; 

96 else 

t = ' ' ; 

end ; 

i f strcmp ( t , ' ' ) , 

100 title( titleText ); 

101 else 

102 title( [titleText ' (' t ')'] ); 

103 end ; 

104 switch (xcol) 

105 case 1, xlabel ( 'Number of Vertices' ); 

106 case 2, xlabel ( 'Number of Edges' ); 

107 case 3, if options. mapx , 

ios% xlabel( [ 1 $$ \ display sty le \ 1 e ft \ 1 c e i 1 \ frac { 1 

num2str (max(d ( : , xcol))) '{\rm modulo }({ \rm Root Vertex ID} ,3) + {\rm Root Vertex 
ID}}{3}\right\rceil$$ '] , 'interpreter', 'latex'); 
109 xlabel( 'Root Vertex ID (Mapped) ' ) ; 

no else 

in xlabel( 'Root Vertex ID' ); 

112 end; 

113 case size(d,2), xlabel( ' Number of Segments' ); 

114 end; 

115 ylabel ( 'Execution Time (ns) ' ) ; 

116 end; 

ii8 i f xcol = 2 , 

no depths = [unique(d(:, xcol)) depths]; 

120 end 

if o p t i o n s . p er c e n t i 1 e < 100, 
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123 d=removeoutliers( d, xcol, 7 , 'greaterthany', options. percentile ); 

124 end ; 

126 if o p t io n s . u s et hre shold limit &&; any( o p t io n s . t hr e s ho Id 1 i mi t ~= ) , 

127 [d o] = removeoutliers ( d, xcol, 4 , 'greaterth an linear', 
op t i ons . t hr es hoi d 1 i m i t ); 

128 else 

129 o = [] ; 

130 end ; 

132 if any (options. betweenx~= [-1 -1]), 

133 d = removeoutliers ( d, xcol, 4, 'notbetweenx', options. betweenx ); 

134 end ; 

136 i f xcol ~= 2 , 

137 depths = removeoutliers ( depths , 1 , 2 , ' notismemberx 1 , unique ( d ( : , 3) ) ) ; 

138 else 

139 depths = removeoutliers( depths, 1, 2, 'notismemberx', unique( d(:, 2) ) ); 

140 depths = depths(:, 2:size(depths,2)); 

141 end 

143 if op t i o n s . p er c e nt i 1 es t e p s = 0, 

144 options. percentilesteps = options. percentile / 16; 

145 end ; 

147 colourSteps = max(ceil( o p t i o ns . p er c e n t i le / options . percentilesteps ) , 1) ; 

148 colourMatrix = getColoursBetween ( opt ions . lowcolour , op t ions . highcolour , 
colourSteps , options . usehsl ) ; 

150 hold on ; 

151 e = d; 

152 prevBounds = options . percentile ; 

153 for j=colourSteps : - 1 : 1 , 

154 if j > 1 , 

155 bounds = o p t i o ns . p e r c e n t i les t ep s * (j - 1) ; 

156 [f e] = removeoutliers ( e, xcol, 7 , 'lessthany', bounds ); 

157 else 

158 bounds = 0; 

159 f = e ; 

160 end ; 

161 x = f ( : , xcol ) ; 

162 if options. mapx , 

163 x = f net (x ,max(x) ) ; 

164 end ; 

165 if op t ions . sho wbandsinlegend , 

166 displayName = [ num2str ( bounds ) '-' num2str ( prevBounds ) ' ~{th} '/.ile 
Data ' ] ; 

167 prevBounds = bounds ; 

168 else 

169 displayName = 11 ; 

170 end ; 

171 handle = plot ( x , f(:,4), '.', 'Color', colourMatrix(j,:), 'MarkerSize', 1, 
'DisplayName ' , displayName) ; 

172 if ~options.showbandsinlegend , 

173 hasbehavior ( handle , ' legend ' , false ) ; 

174 end; 

175 end ; 

177 if ~isempty(o) && o p t io n s . s c al e t h r e s h o Id ~= , 

178 plot( o(:, xcol), o(:, 4)*options.scalethreshold, '.', 'MarkerSize', 1, 

' Color ' , [1 0] , ' DisplayName ' , [ ' Outlying Data (Scale Factor = ' num2str( 
op t i o n s . s c ale t hr e sho Id ) ')'] ); 

179 end ; 

i8i fiterrors = 1 ' : 
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hold all; 

if o pt ions . showbest fit s || op t ions . s ho wdep t hsbes t f i t 
options. showsegmentsbestfit || options. showdepthsumbestfit , 
x = d ( : , xcol ) ; 
7 = d(: ,4) ; 
switch (xcol) 

case {1, 2, size (d, 2)}, % Vertex or Edge 

bf = fitdata2( x, y, options. bestfits, 1 userobustf it 1 , 

op t ion s . u se r o b us t f i t ); 

ux = unique ( x ) ; 

fn = fieldnames ( bf.rmse ); 

num_fn = numel ( f n ) ; 

nc = 0; 

if op t io ns . s ho wbes t f i t s , 
nc = nc + num_fn ; 

end ; 

if opt ions . sho wdep t hsbest fit , 
nc = nc + 1 ; 

end ; 

if options. showdepthsumbestfit , 
nc = nc + 1 ; 

end ; 

if op t ions . sho wsegment sbes t f i t , 
nc = nc + num_fn; 

end ; 

if opt ions . sho wt hresholdl imit , 

nc = nc + 1; 

end ; 

Colours = hsl2rgb([(0:l/nc:l-l/nc)' ones (nc , 1) ones (nc , 1 ) / 2] ) 
colourNum = 0; 
if op t io ns . s ho wbes t f i t s , 
for b = l:num_fn, 

colourNum = colourNum + 1; 

plot( ux, bf.data.(fn{b}), 'DisplayName', 
getLabelText ( bf , fn{b}, op t i o ns . u s er o b us t f i t , 
op t ions . sho wbes t fit rmse , op t ions . sho wbes t fit mae ) , 
1 Color 1 , Colours (colourNum , : ) ) ; 
if opt ions . sho wbest fit rmse , 

fiterrors = [fiterrors ' ' num2str( round ( 
bf.rmse. (fn{b}) ) ) 1 &' ]; yt#ok<AGBOW> 
end ; 

if options. showbestfitmae , 

fiterrors = [fiterrors ' ' num2str( round ( 
bf.mae. (fn{b}) ))'&']; %#ok^GROW> 

end ; 

if o p t io ns . s ho wbes t f i t c is , 

handle = plot( ux , bf.cilower.(fn{b}), 
' Color ' , Colours (colourNum , : ) ) ; 
hasbehavior( handle, 'legend', false ); 
handle = plot( ux , bf.ciupper.(fn{b}), '--', 
' Color ' , Colours (colourNum , : ) ) ; 
hasbehavior( handle, 'legend', false ); 

end ; 

end ; 

end ; 

if opt ions . sho wdep t hsbest fit , 
colourNum = colourNum + 1 ; 
depth = depths (: ,2) ; 
if options . flipdepths , 

depth = flipud( depth ) ; 

end 

dbf = fitdatatoarray( x, y, depth, ' userobustf it ' , 
op t io n s . u s e r ob us t f i t ); 
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237 
238 

239 
240 
241 

242 
243 
244 
245 
246 
247 
248 
249 
250 



252 
253 

254 
255 
256 

257 
258 
259 
260 
261 



263 
264 



265 
266 

267 
268 
269 

270 
271 
272 
273 
274 
275 



276 
277 
278 



plot( ux, dbf.data, 'DisplayName', getLabelText( dbf, 

'depths' , op t i o ns . u ser o b us t f i t , opt ions . showbest fit rmse , 
opt ions . showbest fit mae ) , 'Color' , Colours ( colourNum , :) ) 
if op t ions . showbest fit rmse , 

1 num2str( round( dbf. rmse ) ) 



fiterrors = [fiterrors 



end ; 

if options. showbest fitmae 
fiterrors = [fiterrors 

*• ]; 

end : 



num2str( round ( dbf. mae ) ) 



end ; 

if options. showdepthsumbestfit , 
colourNum = colourNum + 1 ; 
depth = depths(:,2) .* depths(:,3); 
if options . flipdepths , 

depth = flipud( depth ) ; 

end 

dbf = fitdatatoarray( x, y, depth, ' userobustf it 1 , 
op t io ns . us er ob us t f i t ); 

plot( ux, dbf.data, '-', 'DisplayName', getLabelText( dbf, 
' depthsum ' , options . userobustfit , opt ions . showbest fit rmse , 
opt ions . showbest fit mae ) , 'Color' , Colours ( colourNum , :) ) 
if op t ions . showbest fit rmse , 



fiterrors = 

*' 1; 



fiterrors 



end ; 
if 



opt ions, showbest fit mae 
fiterrors = [fiterrors 

*' 1; 



num2str( round( dbf. rmse ) ) 



num2str( round ( dbf. mae ) ) 



end : 



end ; 

if op t ions . sho wsegment sbes t f i t , 

s = filldata(x, depths (:, 3)); 

sf = fitdata2( s, y, o p t i o n s . b e s t f i t s , 'userobustfit' 
op t io ns . us er ob us t f i t ); 
% sf = fitdata3(x, depths (:, 3), 

'userobustfit', options. userobustfit ); 

for b = l:num_fn, 

plot ( ux , sf.data. (fn{b}) , 
regexprep ( getLabelText ( sf 

op t ions . u ser ob us t f i t , op t ions . sho wbest fit rmse 
options. showbestfitmae ), 'x', 's'), 'Color 1 , 
Colours ( colourNum + b,:) ); 



y, o p t i o ns . b es t f i t s 



' , ' DisplayName ' 
fn{b}, 



if opt ions . sho wbest fit rmse 
fiterrors = [fiterrors 
s f . r m se . ( f n {b } ) ) ) ' 

end ; 

if options. showbestfitmae , 
fiterrors = [fiterrors 
sf.mae. (fn{b}) ) ) ' &' 

end ; 



num2str( round ( 

; %#ok^GROW> 



1 num2str( round ( 

%#ok<AGROW> 



end 

end ; 

if opt ions . sho wt hresholdlimit , 
a = axis ; 

plot ( [a(l) a(2) ] , [a(l) a(2) ] 
o p t i o ns . t h r e s h o Id limi t (2 ) , '-' 
Limit', 'Color', Colours(nc, : 
end ; 

3, % Root 

cf = fitdata2( x, y, { 'ones' }, 'userobustfit 
op t i ons . u se r o b us t f i t ); 



. * op t ions . t hr es hoi d li m i t ( 1 ) + 
, 'DisplayName' , 'Threshold 

) ); 
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279 plot ( unique (x) , cf. data. ones , 1 - ' , ' DisplayName ' , getLabelText ( 

cf , 'ones' , op t io n s . us er obus t f i t , opt ions . showbest fit rmse , 
opt ions . showbest fit mae ) ); 

2so if opt ions . showbest fit rmse , 

281 fiterrors = [fiterrors ' ' num2str( round ( cf. rmse. ones ) ) 

& ' ] ; %#ok<AGROW> 

282 end ; 

283 if options . showbestfitmae , 

284 fiterrors = [fiterrors ' ' num2str( round ( cf. mae. ones ) ) ' 

k ' J ; %#ok^GROW> 

285 end ; 

286 if o pt ions . showdept hsbest fit , 

287 bf = fitdatatoarray( x, y, depths (:, 2) , 'userobustfit', 

op t io ns . u s e r ob us t f i t ); 

288 ux = unique ( x ) ; 

289 if ( ~isempty( fnct ) ) 

290 fit = sortrows ( [ fnct (ux, max( ux )) bf.data], 1 ); 

291 plot ( fit ( : , 1 ) , fit ( : ,2) , '-', 'DisplayName', 

getLabelText ( bf , 'depths' , op t io ns . us er ob us t f i t , 

op t ions . showbest fit rmse , opt ions . showbest fit mae ) ); 

292 else 

293 plot ( ux , bf.data, '-', 'DisplayName', getLabelText ( bf, 

'depths' , op t io n s . us er obus t f i t , opt ions . showbest fit rmse , 
op t ions . showbest fit mae ) ); 

294 end ; 

295 if op t ions . showbest fit rmse , 

296 fiterrors = [fiterrors 1 1 num2str( round( bf.rmse ) ) 1 

k ' ] ; %#ok<AGROW> 

297 end ; 

298 if opt ions . showbest fit mae , 

299 fiterrors = [fiterrors ' ' num2str( round( bf.mae ) ) ' 

k ' ] ; %#ok<AGROW> 

300 end ; 

301 end 

302 if opt ions . showt hresholdlimit , 

303 a = axis ; 

304 plot ( [a(l) a(2)[, [a(l) a ( 2 ) ] . * op t i o n s . t hr es hoi d li m i t ( 1 ) + 

options. thresholdlimit(2), '-', 'DisplayName', 'Threshold 
Limit ' ) ; 

305 end ; 

306 end ; 

307 else 

308 if opt ions . showt hresholdlimit , 

309 a = axis ; 

310 plot ( [a(l) a(2)[, [a(l) a ( 2 ) ] . * op t i o n s . t h r es hoi d li m i t ( 1 ) + 
options. thresholdlimit(2), '-', 'DisplayName', 'Threshold Limit' ); 

311 end; 

312 end ; 

313 if options. showbandsinlegend || o p t i ons . s ho wbes t f i t s | 

op t ions . showt hres hold limit || op t ions . s ho wsegme nt sbest f it , 

314 [legendHandle, line Han die] = legend ( 'show', 'Location', 'best' ); 

315 if opt ions . showbandsinlegend , 

316 set ( lineHandle ( ( 1 : colourSteps ) *2 + numel ( lineHandle ) /3 ) , 
' MarkerSize ' , 20 ) ; 

317 end ; 

318 if o p t io ns . sc ale t h r es hoi d ~= &fe ~isempty(o) , 

319 set ( lineHandle ( colourSteps *2 + 2 + numel ( lineHandle ) /3 ) , 
' MarkerSize ' , 20 ) ; 

320 end ; 

321 end; 

322 hold off; 

324 disp( fiterrors ); 

326 if ~strcmp( options. save , 11 ) , 
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% saveas( gcf, options. save, ' png ' ) ; 

% pr in t ( 1 - dpng ', [options. save '.png']); 

print( fig, '-dpng', [options. save '.png'],'-rl50'); % , [ ' - f ' num2str(gcf)[ 

end ; 

function [colours] = getColoursBetween ( lowColour , highColour , steps , useHSL 
) 

^IX>TGRAPHDATA : GETCOLOURSBETWEEN Tweens between two colours in the 
% given number of steps using either RGB or HSL colour spaces. 
% If the number of steps is one, the lowColour is returned, 
if ( steps = 1 ) 

colours = lowColour ; 

else 

i f useHSL , 

lowColour = rgb2hsl ( lowColour ) ; 
highColour = rgb2hsl ( highColour ) ; 

end ; 

c = (0:l/(steps-l) :1) '; 

colours = (1-c) * lowColour + c * highColour; 
if useHSL, 

colours = hsl2rgb( colours ); 

end ; 

end ; 

end % END GETCOLOURSBETWEEN 

function [text] = getLabelText ( bf , name, isRobust , showRMSE, showMAE ) 
text = []; 
if isRobust , 

text = 1 \ newl ine ( Robust Regression'; 

end ; 

if showRMSE, 

if isempty( text ) , 

text = ' \newline ( ' ; 

else 

text = [ text , ' , ' ] ; 

end ; 

if strcmpi ( name, 'depths' ) || strcmpi ( name, ' depthsum ' ) 
strcmpi ( name, 'segments' ), 

text = [text ' RMSE = ' num2str( round ( bf.rmse ) ) ]; 

else 

text = [text 'RMSE = ' num2str( round ( bf. rmse .( name ) ) ) ]; 

end ; 

end ; 

if showMAE, 

if isempty( text ) , 

text = '\newline('; 

else 

text = [ text , ' , ' ] ; 

end ; 

if strcmpi ( name, 'depths' ) || strcmpi ( name, 'depthsum' ) 
strcmpi ( name, 'segments' ), 

text = [ text ' MAE = ' ... 

num2str( round ( bf. mae ) ) ]; 

else 

text = [ text ' MAE = ' ... 

num2str( round ( bf. mae .( name ) ) ) ]; 

end ; 

end ; 

if ~isempty( text ) , 

text = [ text ' ) ' ] ; 

end ; 

if strcmpi ( name, 'depths' ) || strcmpi ( name, 'depthsum' ) || strcmpi ( 
name , ' segments ' ) , 

text = strcat ( bf. equation , text ) ; 

else 
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388 text = strcat ( bf. equation, (name) , text ) ; 

389 end ; 

391 end 

392 end 95END PLOTGRAPHDATA 



rgb2hsl.m and hsl2rgb.m are available from: 

http : //www .mathworks . com/mat labcentral/f ileexchange/20292 
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E.4.9 PlotNumberOfElements.m 



4 


options = struct ( 


' type ' , 


' nogc 1 , 


5 




' f acecolour 1 , 


[.6 .6 .6 


6 




' edgecolour ' , 


[0 0], 


7 




' textcolour ' , 


[0 0], 


8 




1 marker ' , 


1 + 1 , ... 


9 




1 markersize 1 , 


3 , ... 


10 




1 linestyle 1 , 


' none 1 , 


11 




' newf igure ' , 


true , ... 


12 




' yaxis ' , 


, ... 


13 




1 save ' , 


1 1 


14 




' showasbar 1 , 


true ) ; 



function PlotNumberOfElements ( data, t, varargin ) 

% PT DTNI TMRFRO FFT HY TRNTR Plots the number of elements in a data set. 



options = processOptions ( options , ' Graphs : PL0TGRAPHD ATA ' , varargin ) 



switch (data. type) 
case 1 vertex 1 , 
case 1 edge 1 , 
case ' root ' , 
otherwise , 



end ; 

switch options. type 
case ' nogc ' , 
case 1 gc ' , 
case ' error ' , 
case 1 full ' , 
otherwise , 



xcol = 1 ; 
xcol = 2; 
xcol = 3; 

warning( ' Graphs : PLOTNUMBEROFELEMENTS ' , 
'Unknown Data Type: Assuming vertex 

xcol = 1 ; 



x = dat a . dat a . nogc (: , xcol) ; 

x= data. data. gc(:, xcol); 

x= data. data. error (:, xcol); 

x= [data.data.nogc(:, xcol); data. data. 

warning( 1 Graphs : PLOTNUMBEROFELEMENTS 1 , 

'Unknown Type: Assuming nogc' ); 
x = dat a . dat a . nogc (: , xcol) ; 



;c ( : , xcol ) ] : 



end ; 



if options . newfigure , 

screenSize = get(0. 
figure( 'Position' . 



' PaperSize 1 
' Color ' , 



1 ScreenSize ' ) ; 

[ sc reen S ize ( 3 ) /6 screenSize (4) /6 ... 

2*screenSize (3) /3 2* screenSize (4) /3] 
, [20 .98/3 29 .68 / 5] , ... 

' white ' ) ; 



end ; 



num = grpstats( x, x, 1 numel ' ) ; 

hold on ; 

if options. showasbar , 

un = unique ( num ) ; 

nnum = grpstats( num, num, ' numel ' ) ; 

percent = 100*nnum/sum(nnum) ; 

bar( un , percent , ' BarWidth 1 , 0.5 , 'FaceColor' , o p t io ns . f acecolo ur 

'EdgeColor ' , opt io ns . e dgeco lou r ) ; 
title ( t ) ; 

ylabel ( 'Frequency ('/,) ' ) ; 

xlabel ( 'Number of Data Points' ); 

if op t io n s . y axi s > 0, 

axis ( [min(un) - . 5 max(un)+0.5 op t ions . y axi s ] ); 

end ; 

for n = l : numel ( un ) , 

text ( un(n) , percent(n) + .05 * max(percent) , ... 
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[ 1 ( ' num2str( nnum(n) ) ' ) ' ] , ' Color ' , opt ions . t ext co lour 
1 Hor izontalAlignment 1 , 1 center ' ) ; 

end ; 

66 set ( gca , 1 xt ick ' , min( un) : max( un ) ) ; 

67 set ( gca , 1 box 1 , 1 off 1 ) ; 
else 

ux = unique (x) ; 

bf = fitdata2 ( ux , num, { { ' x2 ' , ' x ' } } ); 

plot ( ux , num, 1 Marker ' , options. marker , 1 Color ' , [0 1] , ... 

'LineStyle' , o p t i o n s . 1 i n e s t y 1 e , 'MarkerSize' , opt ions . mar ker size , 
' DisplayName ' , 1 Frequency 1 ) ; 
plot( ux, bf.data.x2_x, 'r-', ... 

'DisplayName' , [ bf . equat ion . x2 _ x ... 
'\newline MAE = ' num2str ( bf .mae .x2 _x ) ] ); 
title ( t ) ; 

78 ylabel ( 'Frequency' ); 

79 switch ( xcol ) 
case 1, xlabel ( 'Number of Vertices' ); 
case 2, xlabel ( 'Number of Edges' ); 

82 case 2, xlabel ( 'Root Vertex ID' ); 

83 end ; 

legend ( 'show', 'Location', 'southoutside' ); 
a = axis ; 

86 axis( [a(l) a(2) max(a(3), 0) min(a(4), 100)] ); 

87 end ; 

if ~strcmp( options. save , 11 ) , 

saveas( gcf, options. save , ' png ' ) ; 

end ; 

hold off; 
end 

function [str] = formatNumber ( n ) 
if n < 0, 

98 str = num2str(n) ; 

99 else 

100 str = [' + ' num2str(n) ] ; 

101 end; 

102 end 
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E.4.10 PlotShowCodeWarmUp.m 



function PlotShowCodeWarmUp ( data , t, varargin) 

9PLOISHOWCDDEVVARMUP(data ,t , varargin) 

% data: Array of Data [vertices edges root time gcCount] 
% t: Title for the graph 



options = struct ( 



' semilogy ' , 
1 ylimit 1 , 
' ypercentile 1 
' usesubplot 1 , 
1 showbetween 1 



' showerrors ' , 

options = processOptions ( options 



false , ... 

- 1 , ... 

- 1 , ... 
false , ... 

[ dat a . dat a. nogc ( 1 , 3 ) ... 
dat a.data.nogc ( 1 , 3) ] , ... 
false ) ; 

' Graphs : PLOTGRAPHD ATA ' , varargin ) 



switch (data. type) 
case 1 vertex 1 , 

case 1 edge 1 , 

case ' root ' , 

otherwise , 



end ; 



xcol = 1 ; 

column = 'Vertex' ; 
xcol = 2; 
column = ' Edge ' ; 
xcol = 3; 
column = ' Root ' ; 

warning( ' Graphs : PLOTGRAPHD ATA 1 , ... 

'Unknown Data Type: Assuming vertex' ) 

xcol = 1 ; 

column = 'Vertex' : 



if options. showbetween ( 1 ) = opt ions . showbetween ( 2 ) , 

t = [t ' (' column ' = ' num2str ( opt ions . showbetween ( 1 ))] ; 

nogc = removeoutliers( data. data. nogc, xcol, 4, ... 

'notequaltox', options, showbetween (1) ); 
if opt ions . showerrors , 



gc 



else 



gc 



= removeoutliers ( [ dat a . dat a . gc ; ... 

[ d at a . d at a . er r or zeros ( s ize ( d at a . dat a . er r or , 1) ,1)] 
] , xcol , 4, 'notequaltox' , options. showbetween ( 1 ) ) 

= removeoutliers ( data. data. gc , xcol , 4, ... 

'notequaltox', options. showbetween(l) ); 



end ; 



else 



= t 



(' column ' = ' num2str ( opt ions . showbetween ( 1 ) ) 
num2str( options. showbetween (2) ) ] ; 
= removeoutliers ( data. data. nogc, xcol, 4, ... 

'notbetweenx', options . showbetween ); 
if op t ions . showerrors , 



nogc 



gc 



else 



gc 



= removeoutliers ( [ dat a . dat a . gc ; ... 

[ d at a . d at a . er r or zeros ( s ize ( d at a . dat a . er r or , 1) ,1)] 
] , xcol , 4, 'notbetweenx' , opt ions . showbetween ) ; 

= removeoutliers ( data. data. gc , xcol , 4, .... 

'notbetweenx', options. showbetween ); 



end ; 



end ; 

if opt ions . showerrors , 

t = [t ', Errors Shown 1 ]; 

end ; 

screenSize = get ( , ' S cr eenS ize ' ) ; 

figure ( 'Position' , [ scr ee n S iz e ( 3 ) /6 sc reen S i ze (4 ) /6 ... 

2*screenSize (3) /3 2*screenSize (4) / 3] , 
'PaperType', ' a41etter ' , ... 
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100 
101 
1012 
103 

104 
105 

106 
107 

109 
110 
111 
112 
113 
114 
115 
116 
117 
118 



'PaperSize', [20.98 29.68], ... 

1 Color ' , ' white ' ) ; 

if ( op t ions . uses ub p lot ) 

subplot(2,l,l) , semilogy ( nogc (:,6), nogc(:,4), 'b+', ... 

gc(:,6), gc(:,4), 'r+', ' MarkerSize ' , 3 ); 

% Create title 
title( [t ')'] ); 

% Create xlabel 

xlabel ( 'Repetition Number' ); 

% Create ylabel 

ylabel ( ' Time (ns) 1 ) ; 
% Remove bounding box 

set ( gca , ' box ' , ' off ' ) ; 

end ; 

if op t io ns . y pe r ce n t i le > 0, 

nogc = removeoutliers ( nogc, xcol , 7, ... 

' gr eat er thany ', options. ypercentile ); 
gc = removeoutliers ( gc , xcol, 7, ... 

'greaterthany', options. ypercentile ); 
t = [t ', Time <= ' num2str ( o p t i o n s . y per c e n t i le ) ' th Percentile']; 

end ; 

if op t i ons . y 1 i mi t > 0, 

nogc = removeoutliers ( nogc, xcol, 4, ... 

'greaterthany 1 , options. ylimit ); 
gc = removeoutliers ( gc , xcol, 4, ... 

'greaterthany 1 , options. ylimit ); 
t = [t ', Time <= ' num2str ( op t i ons . y 1 i mi t ) 'ns']; 

end ; 

% Plot data 

if ( opt ions . semilogy ) 

if ( op t ions . usesubplo t ) 

subplot (2,1,2), semilogy ( nogc ( : , 6 ) , nogc (:,4), 'b+', gc(:,6), gc(:,4) 
' r+ 1 , ' MarkerSize ' , 3 ) ; 

else 

semilogy ( nogc (:,6), nogc(:,4), ' b+ ' , gc(:,6), gc(:,4), 'r+', 
' MarkerSize ' , 3 ) ; 

end ; 

else 

if ( options . usesubplot ) 

subplot (2 , 1 ,2) , plot( nogc(:,6), nogc(:,4), 'b+', gc(:,6), gc(:,4), 
' r+ ' , ' MarkerSize ' , 3 ) ; 

else 

plot ( nogc ( : ,6) , nogc (:,4), ' b+ 1 , gc(:,6), gc(:,4), ' r+ 1 , 'MarkerSize' 

3 ); 

end ; 

end ; 

% Create title 
title ( [t ' ) ' ] ) ; 

% Create xlabel 

xlabel( 'Repetition Number' ); 

% Create ylabel 
ylabel ( ' Time (ns ) ' ) ; 

% Create legend 

legend ( { ' Unint errupt ed by GC', 'I nt err up ted by GC' }, 'Location', 'Best' ); 

% Remove bounding box 
set ( gca , ' box ' , ' of f ' ) ; 
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E.4.11 processOptions.m 



function [options] = processOptions ( options , fnctName , user Arguments ) 



for k =l:2:numel( user Arguments ) 
if ischar( user Arguments {k} ) 



isfield( options, lower ( user Arguments {k} ) 



15 
16 



19 
20 



31 
32 



35 
36 



39 
10 



opt = o pt ions .( lower ( userArguments{k} )); 
if k + 1 <= numel ( user Arguments ) , 

if strcmp( class ( opt ) , class ( user Arguments {k +1} ) ) , 
switch class ( opt ) , 

case { ' struct ' , 1 logical 1 , ' char ' , 1 cell 1 } , 

op t ions .( lower ( user Arguments {k }) ) = userArguments{k + l}; 
otherwise , 

if size( opt, 1 ) = size( user Arguments {k + 1} , 1) &fe .. 

size ( opt, 2 ) = size ( user Arguments {k + 1} , 2), 
options. ( lower (userArguments{k})) = 
user Arguments {k + 1 } ; 

else 

warning ( fnctName, ... 

['Invalid option: ' ... 
userArguments{k} ' 
num2str( size( opt 
num2str( size( opt 



should be size 
, 1 ) ) 'x' ... 

■ 2 ) )] ); 



end ; 



end ; 



else 



switch class ( opt ) , 

case ' struct 1 , warn = ' struct ' ; 

case 1 logical 1 , warn = ' logical ' ; 

otherwise, warn = [ class ( opt ) ' [' 
num2str( size ( opt, 1 ) ) 'x 
num2str( size ( opt, 2 ) ) ' ] 

end ; 

warning ( fnctName , ... 

['Invalid option: ' user Arguments {k} 
' should be type ' warn ] ) ; 



end ; 



else 



warning ( fnctName, ... 

['Not enough parameters: 



user Arguments {k } ] ) 



end : 



else 



warning( fnctName, ['Invalid Option: 



user Arguments {k } ] ) ; 



end ; 



end ; 
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E.4.12 removeoutliers.m 



function [output, varargout ] = r emo veou t liers ( data . 

% Function to remove outliers 



xcol , ycol , type, limit) 





switch lower ( type ) , 












case 


1 lessthanx ' , 


mitlviTltr 

U U U 1 V 1 11 ti 


= data ( 




xcol) <C li m i t ' 




case 


1 1 e s s t hany ' , 


mitlumo 

U U bl J 111 


= data ( 




\r c n 1 1 <~" 1 i in i f ■ 
y nil i — , 1 1 ill li, 


7 


case 


1 1 e s s t hano r e qualx ' , 


outlying 


= data ( 




xcol) li jxi i t ; 




case 


' lessthanorequaly ' , 


outlying 


= data ( 




ycol) li m i t ; 




case 


1 gr e at er t hanx 1 , 


rtiitlvinir 
U 11 I IV lilt 


= data ( 




V" f t \ | j 1 l \ } | i 1 ■ 

At,Ul 1 ^ 1 1 111 1 L , 




case 


' greaterthany ' , 


outlying 


= data ( 




ycol) ^> li m i t ' 




case 


' greaterthanorequalx 


' nlif 1 viti o 
, UUulVlUg 


= data ( 




xcol ) >= limit ; 


12 


case 


' greaterthanorequaly 


1 , outlying 


= data ( 




ycol ) >= limit ; 




case 


1 equaltox 1 , 


fllltlwM IT 

U U I 1 V 


= data ( 




xcol ) = limit ; 




case 


1 equaltoy ' , 


outlying 


= data ( 




ycol ) = limit ; 




case 


1 notequaltox 1 , 


outlying 


= data ( 




xcol ) ~= limit ; 




case 


1 notequaltoy 1 , 


fllltl VI Tl ff 
UULlylllti 


= data ( 




ycol ) ~= limit ; 




case 


1 notbGtwssnx 1 , 


outlying 


= ( data ( : , 


xcol ) < limit ( 1 ) | 


18 








data ( : , 


xcol ) > limit (2) ) ; 


19 


case 


1 no t be t we eny 1 , 


outlying 


= ( data ( : , 


ycol ) < limit ( 1 ) | 










data ( : , 


ycol ) > limit (2) ) ; 




case 


1 notwithinx 1 , 


outlying = 


= ( data ( : , 


xcol) <= limit ( 1 ) 










data ( : , 


xcol ) >= limit (2) ) ; 




case 


1 notwithiny 1 , 


outlying 


= ( data ( : , 


ycol) <= limit ( 1 ) 










data ( : , 


ycol ) >= limit (2) ) ; 




case 


1 morethansdf rommeanx 


1 , d = data ( 


: , xcol ) 












s = abs(d 


- mean 


: d 


)) / std( d); 


27 






outlying 


= s > limit ; 


28 






clear d s 








29 




i 

more'CnanSQironinieany 


' , d = data ( 


: , ycol ) 






30 






s = abs(d 


- mean 


: d 


)) / std( d); 


31 






outlying 


= s > limit ; 


32 






clear d s 








33 


case 


1 greaterthanmeany 1 , 


x = data ( 


: , xcol ) ; 




34 






y = data ( 


: , ycol ) ; 




35 






ux = unique (x) ; 






36 






outlying 


= zeros 


{ size (x) ) ; 


37 






filter = 


grpstats (y 


, x , 1 mean 1 ) + limit ; 


38 






for i = 1 : numel ( f i 1 1 e r ) 


39 






outly 


ing = o 


ut lying + (x = ux(i)) 








filter ( i )) ; 






40 






end ; 








41 






clear x y 


filter 


ux 




42 


case 


' greaterthanypercent 


ile ' , 








43 






x = data ( 


: , xcol ) ; 




44 






y = data ( 


: , ycol ) ; 




45 






ux = unique (x) ; 







•(y > 



outlying = zeros ( size (x) ) ; 
filter = gr oupe dper cent iles ( [ x y], limit) 
for i = 1 : numel ( fi It e r ) 

outlying = outlying + (x = ux ( i ) ) . * 
filter ( i )) ; 

end ; 

clear x y filter ux : 



case ' not i smember x ' , 

case 1 not i smember y 1 , 

case 1 ismemberx ' , 

case 1 ismembery ' , 

case ' greaterthanlinear 1 

limit(l) + li m i t ( 2 ) ) ; 

otherwise , 



outlying 
outlying 
outlying 
outlying 
outlying 

outlying = 



~is member ( data(:,xcol), limi 
~ismember( data(: ,ycol) , limi 
ismember ( data(:,xcol), limit 
ismember( data(: ,ycol) , limit 
data(:,ycol) > (data (:, xcol ) 



(y > 



t ) 
t ) 

); 
); 



end ; 
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output = data ; 

output (any ( outlying, 2) , :) = []; 
i f nargout > 1 , 

inverse = data; 

inverse ( any (~outlying, 2 ) , :) = 
varargout {1} = inverse; 

end ; 



General Mathematical Notations 



Name 



Description 



Pg. 



A Boolean And: The statement / A g is true if both / and g are true 460 

otherwise it is false. 

V Boolean Or: The statement / V g is true if either / or g (or both) are 460 

true otherwise it is false. 
/ Negation: A slash through a symbol denotes the inverse of that 460 

symbol's meaning. I.e. 7^ denotes not equals; <^ denotes the "is not 
an element of" relationship; and $x G X : f{x) denotes that no element 



[x\ 

1*1 

G 
C 

n 

\ 
u 
3 

3! 

V 



{...} 



Ceiling: Round x up to the nearest integer. 
Floor: Round x down to the nearest integer. 
Round: Round x to the nearest integer. 



460 



460 

Cardinality: The cardinality (size) of set x. 460 
Set Membership: x g X denotes that £ is a member of the set X. 460 
Subset: X C y denotes that every element of X is also an element of y. 460 



Proper Subset: X c y denotes X c y A X ^ y. 460 
Set Intersection: AnB denotes the set of those elements which are 460 
contained in both A and B. 

Set Complement: A\B denotes the set of those elements which are 460 
contained in A that are not in B. 

Set Union: A^JB denotes the set of those elements which are contained 460 
either in A, or in B, or in both. 

Exists: 3x G X : f(x) denotes that at least one element x exists in the 460 
set X such that f(x) is true. 

Uniquely Exists: 3\x g X : f(x) denotes that exactly one element x 460 
exists in the set X such that f(x) is true. 

For All: ViGl: f(x) denotes that every element x in the set X is 460 
such that f(x) is true. 

Equivalence Relationship: f = g denotes that / and g have an 460 
equivalence relationship. 



Set: An unordered collection of distinct objects. A set can be defined 460 
with the notation: 

• {a, /3, 7,...} denoting an (unordered) collection of the listed 
elements. 

• {x G X : f(x)} denoting the set containing each element x from 
the super-set X where f(x) is true. 

• For example: {n G Ni : n < 5} = {3, 1, 4, 2, 5}. 



460 



General Mathematical Notations 



461 



Name 


Description 


Pg. 





Empty Set: A set containing no elements. 


460 



(. . .) Sequence: A set of elements paired with a total order over those 460 

elements. A sequence can be defined with the notation: 

• (a, (3, 7, . . .) denoting a sequence containing the elements, and in 
the order, as listed. 

• (S, 31) denoting a sequence containing the elements in set § and 
the relationship H which induces a total order over S. 

• For example: ({n e Ni : n < 5} , >) = (5, 4, 3, 2, 1). 



Graph Notations 



Name 



Description 



Pg. 



Upper Case Typically denotes a collection (set, sequence, graph, etc.) of elements. 





£ 


Edges, Set of: The set £ of edges of the graph. 


28 




£\5F 


Cotree Edges, Set of: The set £\J of edges not contained in the 
spanning tree of the graph as defined by a Tremaux Tree. 


28 






Tree Edges, Set of: The set 2r of edges contained in the spanning 
tree of the graph as defined by a Tremaux Tree. 


28 




S 








S(V,£) 


Graph: A (connected) graph with set V of vertices and the set £ of 
edges. 


28 




T 


Tremaux Tree (Short Form): Shortened form of T(S,3 r , r). 


28 






Tremaux Tree: A Tremaux Tree T explicitly defined, for graph 
S iy, £), as partitioning the edges into the set 2f of tree edges (and the 
set Z\J of cotree edges) and where vertex r is the root of the tree. 


28 




V 


Vertices, Set of: The set V of vertices for the graph. 


28 


Lower Case 
Letter 


Typically denotes a single element/object (number, vertex, edge, etc.). 














Edges 








{u,v} 


Edge: An undirected edge connecting vertices u and v. 


28 






Directed Edge: An directed edge outbound from vertex u and 
inbound to vertex v. 


28 














Cotree Edge: A directed edge that is also a cotree edge. 


28 


Intervals 




[u;v] 


Chain: An ordered closed interval of graph elements from minimum it 
to maximum v, inclusive, such that all elements are related, and ordered, 
via -< and that the chain is maximal with regards to set inclusion. 

[u; v] = ({x £ V U £ : u 4 x 4 v} , -<) 


31 




]u; v] 


Chain Excluding Minimum: ]u; v] = ({x £ V u £ : u -< x 4 v} , -<) 


31 




[u;v[ 


Chain Excluding Maximum: [u; v[ — ({x £ V U £ : u 4 x -< v} , -<) 


32 




)u;v[ 


Chain Excluding Minimum and Maximum: 


32 


Relations 




4 


Precedes OR Equals: u =4 v if, and only if, u is contained in the path 
from r to v within the Tremaux Tree. 


28 
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Graph Notations 
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Name 


Description 


Pg. 




Precedes: u if, and only if, u v A u =^ v . 


28 


"mm 


Immediately Precedes: u -<! im d if, and only if, u -< v and no element 
x exists such that u -< x -< v. 


28 


_L 


Comparable Precedence: ^u^wVw^u. 


28 


Edge 






Relations 






-<* 


TT Precedence (Partial Order): 

(u-tv) -< (u—tw) (lowPointl -< lowPomtl ((u— s> w)j) V 
(lowPointl (ei) = lowPointl (e 2 ) A lowPoint2 (ei) =tiA lowPoint2 (e 2 ) -< 


30 


II * 


Incomparable TT-Precedence: 

(u-tv) ||* (u-»io) (lowPointl ((«-»«)) = lowPointl ((u-)-ty))) A 
((u = lowPoint2((w^u)) = lowPoint2 ((u ->• to))) V 
(lowPoint2 -< it A lowPoint2 ((u — > u>)) -< u)) 


30 




TT Precedence (Total Order): 

(u->v) <** (u-tw) (((u4») -<* (u ->«;)) A ||* (u-no) 
and (u— > u) is arbitrarily ordered before (u —)•«;))) 
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Segments 


< s 


Segment Precedence: A total order over the set of segments. 


38 


head (s) 


Head: The head (minimal -< precedence) element of segment s. 


32 


headEdge (s) 


Head Edge: The edge with minimal -< precedence within segment s. 


32 


headVertox f s*l 


Head Vertex: The vertex immediately preceding the head edge for 
segment s. 


32 


tail (s) 


Tail: The tail (maximal -< precedence) element of segment s. 


32 


tailEdgc (s) 


Tail Edge: The edge with minimal -< precedence within segment s. 


32 


tailVertex (s) 


Tail Vertex: The vertex the tail edge for segment s is inbound to. 


32 




Head Edge (compact notation): The edge with minimal -< 


41 




precedence within segment s. 






Head Vertex (compact notation): The vertex immediately 
preceding the head edge for segment s. 


41 




Tail Edge (compact notation): The edge with minimal -< 


41 




precedence within segment s. 






Tail Vertex (compact notation): The vertex immediately 
preceding the tail edge for segment s. 


41 


"fx 


First Low Point Vertex (compact notation): The minimal prece- 


41 




dence vertex reachable from segment s (vf = lowPointl (head (s))). 




uf 


First Low Point Vertex (compact notation): The sec- 


41 




ond lowest precedence vertex reachable from segment s (vf = 
lowPoint2(head(s))). 




Embeddings 






r 


Embedding: An embedding; assumed to be a planar embedding unless 
otherwise stated. 
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M 


Surface: A surface (orientable, genus 0, two-dimensional topological 
manifold) onto which an embedding is performed. 


40 




Faces: The set 3 of faces defined by an embedding T within a surface 
M is such that the union of all faces is the complement of the embedding 
(M\r) and that each face is a maximal set of connected points within 
that complement. 


40 



Glossary 



Name 



Description 



Symbol 



Pg. 



adjacent 



ancestor 



articulation vertex 



biconnected com- 
ponent 

biconnected graph 



block 



In the abstract, two distinct vertices are 
adjacent if they are connected by an edge. 

Specifically relating to embeddings an 
element (vertex or edge) is adjacent to a face 
if the embedding of that element is on the 
boundary of that face. Similarly, a segment is 
adjacent to a face (or region) if any element 
contained in that segment is adjacent to that 
face (or region). 



A given segment's ancestors are those segments 
containing an element which precedes an 
element of that given segment (or, simply, 
segment s a is an ancestor of segment sp if 
head(s Q ) -< head(s J g)). The (root) segment 
containing the root vertex of the Tremaux Tree 
has no ancestors but is an ancestor of every other 
segment. 

An articulation vertex is a boundary vertex 
in a 1-separation (such that deletion of that 
articulation vertex separates the connected 
component containing that vertex forming two 
disconnected connected components). 
A biconnected component is a maximal 2- 
separable (2-connected) sub-graph. 
A biconnected graph is a graph such that if 
any element (vertex or edge) of that graph is 
removed then all other elements of that graph 
remain connected. A biconnected graph is k- 
separable such that k > 2. 

A block of segments is a group of segments, 
related via conflicts, which all have embeddings 
within either the inside or outside region 
adjacent to a common ancestor where the 
embedding of any one segment from that 
block within one of those regions defines the 
embedding of each other segment of that block 
to be in either the same or opposite region. 
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Glossary 






465 


Name 


Description 


Symbol 


Pg. 


branch 


A branch, of the Tremaux Tree of graph S (V, £), 
rooted at an element (vertex or edge) x is 
the sub-tree S'(V,£') containing only those 
elements preceded by, or equalling, x; i.e. such 
that (to G V : v G V A x =4 v) and (Ve G £' : e € 
£ A x =<; e) . The branch rooted at the root of a 
Tremaux Tree is the entire Tremaux Tree. 




28 


bridge edge 


A bridge edge of a graph is an edge that is 
not contained in any biconnected component of 
that graph. Deletion of a bridge edge separates 
the component containing that edge into two 
disconnected components. All bridge edges 
are tree edges (see corollary 4.1.21) and their 
adjacent vertices are articulation vertices. 




36 


chain 


A chain is an ordered sequence of graph elements 
(a path) such that: within the Tremaux Tree, all 
elements of that chain are related, and ordered, 
via -<; and that the chain is maximal with 
regards to set inclusion. 




31 


child 


A given segments children are the set of 
segments whose parent is that given segment. 


[a; 13] 


33 


component 


A fc-separable component is a maximal k- 
separable sub-graph. 








• A component (without qualifier), or con- 
nected component, indicates a 1-separable 
component. 

• A biconnected component indicates a 2- 
separable component (and is a sub-graph 
of a 1-separable component). 

• A triconnected component indicates a 3- 
separable component (and is a sub-graph 
of a biconnected component). 






conflict 


A conflict (or a planarity conflict) occurs when 
two segments do not allow a planar embedding 
within the same region (either inside or outside) 
relative to a common ancestor. 




50 


connected graph 


A graph such that a path exists connecting every 
pair of elements within that graph. A connected 
graph is /c-connected such that k > 1. See also: 
biconnected graph. 




467 


cotree edge 


A cotree edge (u i>) of 9 is an edge that is 
not contained in the spanning tree defined by 
the Tremaux Tree of 9- 


£\5F 


G 28 


curve 


Topologically, a curve 7 is a continuous mapping 
7 : J — > "P from one-dimensional (an interval 
3 of real numbers) to n-dimensional space (a 


7 


466 











Glossary 
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Name 


Description 


Symbol 


Pg. 


curve, closed 


A closed curve 7 is where the mapping 7 : 3 — > 7 
is such that letting 3 — [a; b] then 7(a) = 7(6); 
i.e. the curve has no end-points and completely 
encloses an area. 




40, 
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curve, open 


An open curve 7 is where the mapping 7 : 3 — > 3> 
is such that letting 3 = [a; b] then 7(a) 7^ 7(6); 




40, 
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curve, simple 


A simple open curve 7 is such that the mapping 
7 : 3 — > J" is injective - i.e. the curve does not 
intersect itself. 

A simple closed curve 7 : [a; b] — > 5 is such that 
[a; 6[ — » 3 is injective and that 7(a) = 7(6) - i.e. 
the curve forms a loop which does not intersect 
itself. 






cycle 


A cycle is a closed path (where the first and last 
element of the path are the same and that each 
vertex of the cycle is incident to an even number 




466 




of edges also contained in that cycle). 






cycle, simple 


A simple cycle is a cycle where each vertex of 
the cycle is incident to exactly two edges of the 
cycle; i.e. the cycle forms a single loop that does 
not intersect itself. Each simple cycle's planar 
embedding forms a Jordan curve. 






degree 


The degree of a vertex is the number of edges 
incident to that vertex. 






descendant 


A given segment's descendants are those 
segments containing an element which succeeds 
an element of that given segment (or, simply, 
segment s a is a descendant of segment sp if 
head (sp) ~< head (s a ))- Every non-root segment 
is a descendant of the root segment. 
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edge 


A connection between a distinct pair of vertices 
- if looping edges are allowed then edges can 
connect a non-distinct pair of vertices. 


{u, v} € £ 


467 


element 


Each element of a graph is a fundamental unit 
(vertex or edge) of that graph. 




29 


embedding 


An embedding of a graph S (V, £) on a surface 
M is a mapping from each vertex of S to a point 
on M and from each edge to a open curve (or, 
for a looping edge, a closed curve) such that 
the end-points of the curve are at the points 
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Name 



Description 



Symbol 



Pg. 



embedding, planar 



graph 



A planar embedding T of a graph 9 (V, £) is 
an embedding on a surface M (assumed to be 
orientable and genus 0) such that each vertex 
maps to a distinct point on M and each edge 
corresponds to a Jordan arc (or Jordan curve 
for looping edges) such that no arc (curve) 
intersects with itself (by definition of it being 
a Jordan arc/curve), another arc nor a point 
corresponding to a vertex, except to terminate 
at the points corresponding to its incident 
vertices. 

A face / is a maximal set of connected points 
within the complement (M\T) of an embedding 
r on a surface M. 
A graph 9 is an ordered pair (V, £) consisting of 
a set V of vertices and a set £, disjoint from V, 
of edges, together with an incidence function ipc, 
that associates with each edge of 9 an unordered 
pair of (not necessarily distinct) vertices of 9- 
If e is an edge and u and v are vertices such 
that ips ( e ) = i u i v } then e is said to connect u 
and v, and the vertices u and v are said to be 
incident to e and to terminate e. The numbers 
of vertices and edges in 9 can be denoted by |V| 
and |£|, respectively. All graphs are assumed to 
be connected graphs unless otherwise stated. 
A vertex v and an edge {a, 6} are incident if, 
and only if, v = a V v = b. A segment s is 
incident to a vertex v if v is not contained in 
s but is incident to an edge (either the head or 



Jordan arc A Jordan arc is a simple open curve. 

Jordan curve A Jordan curve is a simple closed curve, 

fc-separable A graph 9 (V, £), is fc-separable (or fc-connected) 

if to separate 9 (V, £) into two disconnected 
components requires a minimum of fc distinct 
vertices to be removed from that graph (i.e. 
there exists a fc-separation and there does not 
exist a k — 1-separation). 
fc-separation For a graph 9 (V, £), a fc-separation is a partition 

on the edge-set £ of 9 into the sub-sets £' and 
£\£' such that the sub-graphs induced by both 
edge-sets are non-empty and connected and that 
there are exactly k boundary vertices common 
to both incident sub-graphs. An articulation 
vertex is the boundary vertex for a 1-separation. 
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Name 




Description Symbol 


Pg. 


leaf 




A leaf of a Tremaux Tree is an element where 
no other clement succeeds it (i.e. a vertex with 
no outbound edges or a cotree edge). Each leaf 
terminates a branch of the Tremaux Tree and 
its containing segment. 


34 


low point 
first 


vertex, 


A given element's first low point vertex is 
the minimum precedence vertex of that given 


29 


low point 
second 


vertex, 


A given element's second low point vertex is the 
second minimum precedence vertex of that given 
element's low point vertices. If the element only 
has a single low point vertex then that low point 
vertex is both the first and second low point 
vertex. 


29 


low point vertices 


A given element's low point vertices are those 
vertices which precede or equal that given 
element (within the Tremaux Tree) and are 


29 



incident to edges contained in the sub- Tremaux 



microsecond 


One millionth (10~ 6 ) of a second. 


lis 


104 


millisecond 


One thousandth (10 -3 ) of a second. 


ms 


104 


nanosecond 


One thousand millionth (10~ 9 ) of a second. 


ns 


104 


parent 


A given segment's parent is its ancestor 
which contains the highest precedence element 
preceding that given segment (or, simply, 
segment s a is the parent of the distinct segment 
sp if headVertex (s^) £ s a ). The root segment 
has no parent; every other segment has a parent. 
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path 


A path is a sequence (ei, . . . , e„) of 
distinct edges, corresponding to a sequence 
(vo> Vi, v 2 , ■ ■ ■ , v n ) of vertices incident to those 
edges, such that a = i.e. each given 
edge of the path has one incident vertex which 
is also incident to the preceding edge of the 
sequence (assuming it is not the first edge of the 
sequence) and its other incident vertex is also 
incident to the succeeding edge of the sequence 
(assuming it is not the last edge of the sequence) . 






path, closed 


A closed path is a path where the elements 
terminating the path are identical; i.e. the path 
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forms a cycle. 






path, open 


An open path is a path where the elements 
terminating the path are distinct; i.e. the path 
does not form a cycle. 






path, simple 


A simple path is a path where no strict sub- 
path of that path is a cycle; i.e. no more that 
two edges on a simple path are incident to any 
one vertex also on that path. 
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Name 


Description Symbol 


Pg. 


reachable 


A given element's reachable elements are those 


29 




elements contained in the sub-tree of the 






Tremaux Tree rooted at that given element and 






any vertices incident to edges contained in that 






sub-tree (which may be contained in that sub- 






tree or precede it). 




region (relative to 


A region relative to a segment is defined by 
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smaller faces contained within that region 






(which, themselves, are regions relative to those 






subsequent segments), however that region is 






constant. 






• Each Class 1 segment has exactly one 






adjacent region. 






• Each Class 2, 3 or 4 segment has exactly 






two adjacent regions - designated as inside 






and outside. 




root 


The vertex designated to be the root of the r 
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Tremaux Tree and, hence, having minimal < 






precedence. 




root (of a branch of 


The element (vertex or edge) having minimal -< 




a Tremaux Tree) 


precedence within the branch of the Tremaux 






Tree. 




rooted spanning 


A spanning tree where one vertex is designated 
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tree 


as the root vertex. A rooted spanning tree 






can be given direction such that all edges are 






directed relative to the root vertex (typically all 






edges are directed away from the root vertex). 




segment 


A path of ~< related vertices and/or edges 
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• i 1 • j • / i~\ £~\ \ -T-~\ 1 

with specihc properties (see page 32). Each 






connected graph can be partitioned into a set 






of disjoint segments. 




segment, root 


The root segment is the segment containing the 


33 




root vertex of the Tremaux Tree; it has no 






ancestor (hence, no parent or siblings) and each 






onici oegmtiii lb one oi ilb ueBceiiuaniB. 




sibling 


Two segments are siblings if they share the same 


33 




parent. 




spanning tree 


A sub-graph of a given connected graph which 


469 




is a tree that covers all vertices of that given 






graph. 




sub- graph 


A sub-graph of a given graph is a graph 






composed of a (strict or non-strict) sub-set of 
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Name 


Description 


Symbol 


P g . 


surface 


A two-dimensional topological mamlold. In the 
context of this work, all surfaces are assumed to 
be orientable and have genus 0; i.e. the R 2 plane 
or the surface of a sphere. 




40 


tree 


A connected graph containing no looping edges 
or cycles. 




469 


tree edge 


A tree edge (u -^v) of S is an edge contained in 
the spanning tree defined by the Tremaux Tree 
of S. 
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Tremaux Tree 


A Tremaux Tree (T (S, J, r)) of graph (3 (V, £)) 
defines a root vertex r and a partitioning of 
the set £ of edges of S into two disjoint sets: 
the set J of tree edges which compose a rooted 
spanning tree of S (rooted at r); and the set 
£\3 r of cotree edges. All edges (tree and cotree) 
of the Tremaux Tree connect a pair of vertices 
which are comparable via the =<; relationship. 


TT 


28 


vertex 


A fundamental unit of a graph. 
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Graphical Notations 



Name 



Description 



Pg- 



Vertex 

Vertex (and 

optional 
descendants) 



O 

A vertex and (optional) chains of descendants forming a 
(partial) sub-tree; this is represented graphically by an 
oversized vertex entity. Note: A tree edge represented as 
being inbound to this graphical entity is inbound to the 
minimum precedence vertex rooting the sub-tree; any other ( outbound 
or inbound cotree) edge incident to this graphical entity can be can be 
incident to any vertex contained within the represented sub-tree - where 
two such incident edges can be within different branches of the sub-tree. 




All 



471 



Root Vertex 
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Undirected 

Edge 
Tree Edge 

Cotree Edge 

Chain 
(non-empty) 

Chain 
(possibly 

empty) 



▼ 



'V/V*- A chain containing one or more edges. 



A chain containing zero or more edges. 
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